Hi Daniel,
Daniel Vetter writes:
On Fri, Mar 29, 2013 at 5:35 PM, Egbert Eich e...@suse.com wrote:
Yeah, makes sense now that I think about it - I've simply didn't look
ahead in your patch series while writing this little fixup ;-) Can you
just re-add this when resending your patches
Hi Dave,
So I've figured we should get drm-next for 3.10 started ;-)
Highlights:
- Imre's for_each_sg_pages rework (now also with the stolen mem backed
case fixed with a hack) plus the drm prime sg list coalescing patch from
Rahul Sharma. I have some follow-up cleanups pending, already acked
On Fri, Mar 29, 2013 at 09:54:50AM -0700, Stéphane Marchesin wrote:
On Fri, Mar 29, 2013 at 5:54 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
That's a problem as we would need a running pipe, which is not
guaranteed. I wonder if CLOCK_MONOTONIC would suffice?
Yeah that's what I had
On Thu, Mar 28, 2013 at 09:55:37AM -0700, Jesse Barnes wrote:
No constant alpha yet though, that needs a new ioctl and/or property to
get/set.
v2: use drm_plane_format_cpp (Ville)
fix up vlv_disable_plane, remove IVB bits (Ville)
remove error path rework (Ville)
fix component
On Thu, Mar 28, 2013 at 09:55:44AM -0700, Jesse Barnes wrote:
Slightly different than other platforms.
v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
I think these should DTRT, but with backlight and BIOS you never seem to
know...
BR,
Jani.
Jani Nikula (5):
drm/i915: group backlight related stuff into a struct
drm/i915: protect backlight enable and level with spinlock
drm/i915: don't pretend we support ASLE ALS, PFIT, or PFMB
No functional changes.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 11 +
drivers/gpu/drm/i915/intel_panel.c | 44 ++--
2 files changed, 29 insertions(+), 26 deletions(-)
diff --git
Backlight is fiddled both through backlight sysfs files and asle
interrupts. Protect the relevant data.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/intel_panel.c | 16
2 files changed, 17 insertions(+)
In theory, this should prevent the BIOS from requesting them from us, and
this should be the right thing.
In practice, this is not always the case, and might surprise the BIOS.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_opregion.c |4 +---
1 file
In theory, the BIOS should not even request these from us now that we
aren't claiming we support these, but when it does anyway, don't pretend it
succeeded. It should be the right thing to do, but might confuse the BIOS.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
With the previous work asle and gse interrupt handlers should now be
functionally the same. Drop the duplicated code.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_irq.c |4 ++--
This is an attempt to make the RGB output color range selection work on VLV.
I also decided to refactor the =gen4 PIPECONF setup code, so that it looks a
bit more like the the ILK/HSW codepaths.
So far this is only compile tested.
___
Intel-gfx mailing
From: Ville Syrjälä ville.syrj...@linux.intel.com
VLV has the color range selection bit in the PIPECONF register.
Configure it appropriately.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 7 +++
1 file changed, 7 insertions(+)
diff
From: Ville Syrjälä ville.syrj...@linux.intel.com
Extract the PIPECONF setup into i9xx_set_pipeconf(). This makes the
=Gen4/VLV code follow the same pattern as the Gen5+ codepaths.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 123
From: Ville Syrjälä ville.syrj...@linux.intel.com
VLV docs still list the the color range selection bit for the HDMI
ports, but for DP ports it has been repurposed.
I have no idea whether the HDMI color range selection bit still works
on VLV, but since we now have to use the PIPECONF color range
On Tue, Apr 02, 2013 at 03:48:10PM +0300, Jani Nikula wrote:
Backlight is fiddled both through backlight sysfs files and asle
interrupts. Protect the relevant data.
It's also used by our modeset code in the lvds/edp enable/disable hooks.
Signed-off-by: Jani Nikula jani.nik...@intel.com
On Tue, Apr 02, 2013 at 03:30:58PM +0200, Sebastian Andrzej Siewior wrote:
mutex_is_locked_by() checks the owner of the lock against current. This
is done by accessing a private member of struct mutex which works on
mainline but does not on RT.
I did not figure out, why this lock-owner-check
On Tue, Apr 02, 2013 at 03:48:09PM +0300, Jani Nikula wrote:
No functional changes.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h| 11 +
drivers/gpu/drm/i915/intel_panel.c | 44
On Tuesday 26 of March 2013 16:49:30 Daniel Vetter wrote:
On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb m...@suse.com wrote:
I have IBM POS machine (4852-570 Truman) that has internal monitor
connected over display port. It reports to have 2 lanes, but only 1
lane works reliably. With 2 lanes
The active output is only the currently selected one, which does not
imply that it's actually enabled. Since we don't use the sdvo encoder
side dpms support, we need to check whether the chip-side sdvo port is
enabled instead.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60138
Bugzilla:
The active output is only the currently selected one, which does not
imply that it's actually enabled. Since we don't use the sdvo encoder
side dpms support, we need to check whether the chip-side sdvo port is
enabled instead.
v2: Fix up Bugzilla links.
Bugzilla:
On Tue, Apr 02, 2013 at 06:39:37PM +0200, Daniel Vetter wrote:
The active output is only the currently selected one, which does not
imply that it's actually enabled. Since we don't use the sdvo encoder
side dpms support, we need to check whether the chip-side sdvo port is
enabled instead.
Still need to mash these into the pipe_config bits, but with the PCH PLL
readout, at least they don't crash after DPMS anymore. So that patch
may be ok to apply as-is; I think the main bits needing rework involve
the mode readout checks in intel_fb.c. They belong in intel_display.c
as part of
From: Chris Wilson ch...@chris-wilson.co.uk
Modifying the clock sources (via the DREF control on the PCH) is a slow
multi-stage process as we need to let the clocks stabilise between each
stage. If we are not actually changing the clock sources, then we can
return early.
Signed-off-by: Chris
This will be shared with wrapping the BIOS framebuffer into the fbdev
later. In the meantime, we can tidy the code slightly and improve the
error path handling.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |7 --
From: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |9 +
drivers/gpu/drm/i915/intel_dp.c |1 +
drivers/gpu/drm/i915/intel_drv.h |8
drivers/gpu/drm/i915/intel_fb.c |
Read the current hardware state to retrieve the active mode and populate
our CRTC config if that mode matches our presumptions.
v2: check that get_hw_state gave us a valid pipe (Imre)
add clock_get for ILK+ (Jesse)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
From: Chris Wilson ch...@chris-wilson.co.uk
As we retrieve the mode from the BIOS it may be constructed using
different assumptions for its configuration, such as utilizing the panel
fitter in a conflicting manner. As such the associated framebuffer may be
insufficient for our setup, and so we
v2: check for non-native modes and adjust (Jesse)
fixup aperture and cmap frees (Imre)
use unlocked unref if init_bios fails (Jesse)
fix curly brace around DSPADDR check (Imre)
comment failure path for pin_and_fence (Imre)
v3: fixup fixup of aperture frees (Chris)
Signed-off-by:
We may need to disable the panel when flipping to a new buffer, so check
the state here and zero it out if needed, otherwise leave it alone.
v2: fixup pipe_set_base check (Imre)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 12
1
Lets us see what's going on if we slowboot instead of fastboot.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
In case we don't get an fb from the BIOS, we may still be able to re-use
existing state and flip a new buffer.
Jesse: Do we want a macro for no mode set or just a new check for
crtc-active here?
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |
On Mon, Apr 01, 2013 at 07:21:59AM +, Sun, Yi wrote:
On Tue, Mar 26, 2013 at 10:00:23AM -0700, Ben Widawsky wrote:
On Tue, Mar 26, 2013 at 04:38:58PM +0100, Daniel Vetter wrote:
On Tue, Mar 26, 2013 at 03:24:37PM +, Damien Lespiau wrote:
There are two ways to run tests,
If we couldn't find a pipe we shouldn't return true. This might be even
better as a WARN though, since it should be impossible to have the port
enabled without a pipe selected.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_ddi.c |2 +-
1 file changed, 1
Shouldn't be possible with return value fixes.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
If we couldn't find a pipe we shouldn't return true. This might be even
better as a WARN though, since it should be impossible to have the port
enabled without a pipe selected.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
1 file changed, 1
We need to properly track PCH PLL sharing configs, and generally set up
PCH PLL state at init time as part of the state readout process.
I-told-you-so-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 51
On Tue, Apr 02, 2013 at 10:03:46AM -0700, Jesse Barnes wrote:
static u32
-intel_framebuffer_pitch_for_width(int width, int bpp)
-{
- u32 pitch = DIV_ROUND_UP(width * bpp, 8);
- return ALIGN(pitch, 64);
-}
Before this patch we need:
statuc u32
On Tue, Apr 02, 2013 at 10:06:37AM -0700, Ben Widawsky wrote:
[Sun, Yi] So what's the conclusion, how can I do to solve the too long time
issue?
I noticed Damien's patches aren't on the branch yet.
If we want to split all i-g-t test cases to different HAS, how can we split
it?
As Imre pointed out, this will do the wrong thing.
Reported-by: Imre Deak imre.d...@intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_drv.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
On Tue, Apr 02, 2013 at 06:16:59PM +0100, Damien Lespiau wrote:
On Tue, Apr 02, 2013 at 10:06:37AM -0700, Ben Widawsky wrote:
[Sun, Yi] So what's the conclusion, how can I do to solve the too long
time issue?
I noticed Damien's patches aren't on the branch yet.
If we want to split
On Thu, Mar 28, 2013 at 09:27:31AM +0200, Jani Nikula wrote:
On Wed, 27 Mar 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
Modifying the clock sources (via the DREF control on the PCH) is a slow
multi-stage process as we need to let the
On Tue, Apr 02, 2013 at 10:03:51AM -0700, Jesse Barnes wrote:
We may need to disable the panel when flipping to a new buffer, so check
the state here and zero it out if needed, otherwise leave it alone.
v2: fixup pipe_set_base check (Imre)
Signed-off-by: Jesse Barnes
On Tue, 2 Apr 2013 19:58:37 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Apr 02, 2013 at 10:03:51AM -0700, Jesse Barnes wrote:
We may need to disable the panel when flipping to a new buffer, so check
the state here and zero it out if needed, otherwise leave it alone.
v2: fixup
On Tue, Apr 02, 2013 at 10:03:56AM -0700, Jesse Barnes wrote:
If we couldn't find a pipe we shouldn't return true. This might be even
better as a WARN though, since it should be impossible to have the port
enabled without a pipe selected.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
On Tue, Apr 02, 2013 at 10:28:11AM -0700, Jesse Barnes wrote:
As Imre pointed out, this will do the wrong thing.
Reported-by: Imre Deak imre.d...@intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
We don't actually support anything w/ bpp%8!=0, so either works.
Actually, for
On Tue, 2 Apr 2013 13:37:50 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Thu, Mar 28, 2013 at 09:55:47AM -0700, Jesse Barnes wrote:
Thus preventing the display from keeping the GT awake with unnecessary
signals.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
On Tue, 2 Apr 2013 13:26:47 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Thu, Mar 28, 2013 at 09:55:37AM -0700, Jesse Barnes wrote:
No constant alpha yet though, that needs a new ioctl and/or property to
get/set.
v2: use drm_plane_format_cpp (Ville)
fix up
On Tue, Apr 02, 2013 at 11:09:30AM -0700, Jesse Barnes wrote:
On Tue, 2 Apr 2013 13:37:50 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Thu, Mar 28, 2013 at 09:55:47AM -0700, Jesse Barnes wrote:
Thus preventing the display from keeping the GT awake with unnecessary
On Tue, 2 Apr 2013 14:37:42 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Thu, Mar 28, 2013 at 09:55:44AM -0700, Jesse Barnes wrote:
Slightly different than other platforms.
v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine.
Signed-off-by: Jesse Barnes
On Tue, 2 Apr 2013 21:14:30 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Tue, Apr 02, 2013 at 11:09:30AM -0700, Jesse Barnes wrote:
On Tue, 2 Apr 2013 13:37:50 +0300
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Thu, Mar 28, 2013 at 09:55:47AM -0700, Jesse Barnes
On Tue, Apr 02, 2013 at 10:03:47AM -0700, Jesse Barnes wrote:
v2: check for non-native modes and adjust (Jesse)
fixup aperture and cmap frees (Imre)
use unlocked unref if init_bios fails (Jesse)
fix curly brace around DSPADDR check (Imre)
comment failure path for pin_and_fence
No constant alpha yet though, that needs a new ioctl and/or property to
get/set.
v2: use drm_plane_format_cpp (Ville)
fix up vlv_disable_plane, remove IVB bits (Ville)
remove error path rework (Ville)
fix component order confusion (Ville)
clean up platform init (Ville)
use
Slightly different than other platforms.
v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine.
v3: drop turbo defines from this patch (Ville)
use PCI_DEVFN(2,0) instead of open coding (Ville)
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Jesse Barnes
On Thu, Mar 28, 2013 at 09:55:39AM -0700, Jesse Barnes wrote:
In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric. Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.
We
On Thu, Mar 28, 2013 at 09:55:41AM -0700, Jesse Barnes wrote:
PPS register offsets have changed in Valleyview.
v2: don't clobber port select bits on VLV when fixing up PPS timings
don't bother with G4x PPS regs (Jani)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by:
On Tue, Apr 02, 2013 at 11:23:05AM -0700, Jesse Barnes wrote:
Slightly different than other platforms.
v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine.
v3: drop turbo defines from this patch (Ville)
use PCI_DEVFN(2,0) instead of open coding (Ville)
Reviewed-by: Ville
On Thu, Mar 28, 2013 at 09:55:46AM -0700, Jesse Barnes wrote:
From: Pallavi G pallav...@intel.com
Program few Tx buffer Swing control settings through DPIO.
Signed-off-by: Pallavi G pallav...@intel.com
Signed-off-by: Yogesh M yogesh.mohan.marimu...@intel.com
Signed-off-by: Gajanan Bhat
On Tue, Apr 02, 2013 at 11:22:20AM -0700, Jesse Barnes wrote:
No constant alpha yet though, that needs a new ioctl and/or property to
get/set.
v2: use drm_plane_format_cpp (Ville)
fix up vlv_disable_plane, remove IVB bits (Ville)
remove error path rework (Ville)
fix component
On Tue, 2 Apr 2013 21:04:29 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Mar 28, 2013 at 09:55:46AM -0700, Jesse Barnes wrote:
From: Pallavi G pallav...@intel.com
Program few Tx buffer Swing control settings through DPIO.
Signed-off-by: Pallavi G pallav...@intel.com
The active output is only the currently selected one, which does not
imply that it's actually enabled. Since we don't use the sdvo encoder
side dpms support, we need to check whether the chip-side sdvo port is
enabled instead.
v2: Fix up Bugzilla links.
v3: Simplify logic a bit (Chris).
On Thu, 28 Mar 2013 10:41:56 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
+ /* DP has a bunch of special case unfortunately, so mark the pipe
+ * accordingly. */
+ bool has_dp_encoder;
Looks pretty good, but I don't think this field is used anywhere?
Maybe it belongs in a
On Tue, 2 Apr 2013 13:47:52 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 28 Mar 2013 10:41:56 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
+ /* DP has a bunch of special case unfortunately, so mark the pipe
+* accordingly. */
+ bool has_dp_encoder;
On Thu, 28 Mar 2013 10:41:57 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We need a flag to designate dp encoders and the dp link m_n parameters
in the pipe config for that. And now that the pipe bpp computations
have been moved up and stored in the pipe config, too, we can do this
On Thu, 28 Mar 2013 10:41:58 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We need it in the fdi m_n computation, which nicely kills almost
all ugly special cases in there.
It looks like we also need this to handle 12bpc hdmi correctly.
Eventually it might be better to switch things
On Thu, 28 Mar 2013 10:41:59 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
The only exception left is is_cpu_edp in the haswell modeset code.
We need that to assign the cpu transcoder, but we might want to
move that eventually into the encoder, too.
Signed-off-by: Daniel Vetter
On Thu, 28 Mar 2013 10:42:00 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We need to be able to read out the hw state code for a bunch
of reasons:
- Correctly disabling boot-up/resume state.
- Pure paranoia.
Since not all of the pipe configuration is e.g. relevant for
fastboot (or at
On Thu, 28 Mar 2013 10:42:01 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Now we can ditch the checks in the Haswell disable code.
v2: add support for Haswell
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 34
On Thu, 28 Mar 2013 10:42:02 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Clock computations and handling are highly encoder specific, both in
the optimal clock selection and also in which clocks to use and when
sharing of clocks is possible.
So the best place to do this is somewhere
On Thu, 28 Mar 2013 10:42:03 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
With the exception of hsw, which has dedicated DP clocks which run at
the fixed frequency already, and vlv, which doesn't have optmized
pre-defined dp clock parameters (yet).
Nice. I think we should do this for
On Tue, Apr 2, 2013 at 11:20 PM, Jesse Barnes jbar...@virtuousgeek.orgwrote:
On Thu, 28 Mar 2013 10:42:03 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
With the exception of hsw, which has dedicated DP clocks which run at
the fixed frequency already, and vlv, which doesn't have
Jesse Barnes noticed in his review of my DP cleanup series that
intel_edp_target_clock is now unused. Checking related code I've
noticed that also intel_edp_link_config is long unused.
Kill them both.
Wrt leaky eDP functions used in the common crtc code, the only thing
still left is
On Tue, 2 Apr 2013 23:27:41 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Jesse Barnes noticed in his review of my DP cleanup series that
intel_edp_target_clock is now unused. Checking related code I've
noticed that also intel_edp_link_config is long unused.
Kill them both.
Wrt
There's a rather decent confusion going on around transcoder m_n
values. So let's clarify:
- All dp encoders need this, either on the pch transcoder if it's a
pch port, or on the cpu transcoder/pipe if it's a cpu port.
- fdi links need to have the right m_n values for the fdi link set in
the
We need a flag to designate dp encoders and the dp link m_n parameters
in the pipe config for that. And now that the pipe bpp computations
have been moved up and stored in the pipe config, too, we can do this
without losing our sanity.
v2: Rebased on top of Takashi Iwai's fix to (again) fix the
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7299ea4..70369e4 100644
---
From: Mika Kuoppala mika.kuopp...@linux.intel.com
In preparation to do analysis of which context was
guilty of gpu hung, store kreffed context pointer
into request struct.
This allows us to inspect contexts when gpu is reset
even if those contexts would already be released
by userspace.
v2:
On Tue, Apr 02, 2013 at 03:45:42PM -0700, Ben Widawsky wrote:
From: Mika Kuoppala mika.kuopp...@linux.intel.com
In preparation to do analysis of which context was
guilty of gpu hung, store kreffed context pointer
into request struct.
This allows us to inspect contexts when gpu is reset
Most importantly this will allow users to set overclock frequencies in
sysfs. Previously the max was limited by the RP0 max as opposed to the
overclock max. This is useful if one wants to either limit the max
overclock frequency, or set the minimum frequency to be in the overclock
range. It also
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_panel.c between commit b1289371fcd5 (Revert
drm/i915: write backlight harder) from Linus' tree and commit
31ad8ec6a614 (drm/i915: group backlight related stuff into a struct)
from the drm-intel
80 matches
Mail list logo
