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-inte
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 fi
On Tue, Apr 02, 2013 at 03:45:42PM -0700, Ben Widawsky wrote:
> From: Mika Kuoppala
>
> 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
From: Mika Kuoppala
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: track i915_hw_context pointers in
Signed-off-by: Ben Widawsky
---
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
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/dri
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 ta
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 cp
On Tue, 2 Apr 2013 23:27:41 +0200
Daniel Vetter 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 leaky eDP functions
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 intel_encoder
On Tue, Apr 2, 2013 at 11:20 PM, Jesse Barnes wrote:
> On Thu, 28 Mar 2013 10:42:03 +0100
> Daniel Vetter 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 (y
On Thu, 28 Mar 2013 10:42:03 +0100
Daniel Vetter 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 common HDMI modes t
On Thu, 28 Mar 2013 10:42:02 +0100
Daniel Vetter 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 in the encoders, wi
On Thu, 28 Mar 2013 10:42:01 +0100
Daniel Vetter wrote:
> Now we can ditch the checks in the Haswell disable code.
>
> v2: add support for Haswell
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 34 +-
> 1 file changed, 25 insert
On Thu, 28 Mar 2013 10:42:00 +0100
Daniel Vetter 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 least we can al
On Thu, 28 Mar 2013 10:41:59 +0100
Daniel Vetter 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
> ---
> drivers/gpu/drm/
On Thu, 28 Mar 2013 10:41:58 +0100
Daniel Vetter 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 around and put the
On Thu, 28 Mar 2013 10:41:57 +0100
Daniel Vetter 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
> without losing our sanit
On Tue, 2 Apr 2013 13:47:52 -0700
Jesse Barnes wrote:
> On Thu, 28 Mar 2013 10:41:56 +0100
> Daniel Vetter 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 t
On Thu, 28 Mar 2013 10:41:56 +0100
Daniel Vetter 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 later patch?
Also
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).
Bugzilla
On Tue, 2 Apr 2013 21:04:29 +0200
Daniel Vetter wrote:
> On Thu, Mar 28, 2013 at 09:55:46AM -0700, Jesse Barnes wrote:
> > From: Pallavi G
> >
> > Program few Tx buffer Swing control settings through DPIO.
> >
> > Signed-off-by: Pallavi G
> > Signed-off-by: Yogesh M
> > Signed-off-by: Gajana
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 compo
On Thu, Mar 28, 2013 at 09:55:46AM -0700, Jesse Barnes wrote:
> From: Pallavi G
>
> Program few Tx buffer Swing control settings through DPIO.
>
> Signed-off-by: Pallavi G
> Signed-off-by: Yogesh M
> Signed-off-by: Gajanan Bhat
Grumpy maintainer is more grumpy:
http://lists.freedesktop.org/
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:
On Thu, Mar 28, 2013 at 09:55:43AM -0700, Jesse Barnes wrote:
> From: Pallavi G
>
> For high res modes m n p calculation is fixed for VLV platform.
>
> v2: use 64 bit types and math (Ville)
>
> Signed-off-by: Pallavi G
> Signed-off-by: Vijay Purushothaman
> Signed-off-by: Yogesh M
> Signed-o
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
> Signed-off-by: Gajanan Bhat
> S
On Thu, Mar 28, 2013 at 09:55:40AM -0700, Jesse Barnes wrote:
> Needed to handle pre/post enable/disable paths on VLV and avoid a few
> fields that are marked reserved on VLV.
>
> v2: don't set color range or DP PLL fields (Jani)
>
> Signed-off-by: Jesse Barnes
This maze of platform checks in o
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.
>
> W
We don't need this until we start using the wait event commands.
v2: move to i915_irq.c (Jesse)
drop unneeded sprite flip done enables (Ville)
v3: drop the DPFLIPSTAT enables altogether (Ville)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_pm.c | 13 -
1 file chan
From: Ben Widawsky
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
fixup thresholds to match other platforms (Ben)
c
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ä
Signed-off-by: Jesse Barnes
Signed-off-by: Jani Nikula
---
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 comp
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_f
On Tue, 2 Apr 2013 21:14:30 +0300
Ville Syrjälä 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ä wrote:
> >
> > > On Thu, Mar 28, 2013 at 09:55:47AM -0700, Jesse Barnes wrote:
> > > > Thus preventing the display from
On Tue, 2 Apr 2013 14:37:42 +0300
Ville Syrjälä 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
> > Signed-off-by: J
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ä 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.
> > >
> > > Sig
On Tue, 2 Apr 2013 13:26:47 +0300
Ville Syrjälä 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 vlv_disable_plane, remove IV
On Tue, 2 Apr 2013 13:37:50 +0300
Ville Syrjälä 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
> > ---
> > drivers/gpu/drm/i915/intel_pm.c |6
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
> Signed-off-by: Jesse Barnes
We don't actually support anything w/ bpp%8!=0, so either works.
Actually, for something like bpp=4, the original code migh
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
These two fixes ar
On Tue, 2 Apr 2013 19:58:37 +0200
Daniel Vetter 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 pipe_set_b
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
tbh I have no i
On Thu, Mar 28, 2013 at 09:27:31AM +0200, Jani Nikula wrote:
> On Wed, 27 Mar 2013, Jesse Barnes wrote:
> > From: Chris Wilson
> >
> > 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
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
As Imre pointed out, this will do the wrong thing.
Reported-by: Imre Deak
Signed-off-by: Jesse Barnes
---
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 b/drivers/gpu/drm/i915/intel_drv.h
index 37f4bb3..18
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?
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 intel_framebuffer_pitch_for_wid
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
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 51 ++
1 file changed
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
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(
Shouldn't be possible with return value fixes.
Signed-off-by: Jesse Barnes
---
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
index 208dde4..af0f5c4 100644
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
---
drivers/gpu/drm/i915/intel_ddi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
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
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
---
drivers/gpu/drm/i915/intel_display.c |4 +---
1 file changed
Lets us see what's going on if we slowboot instead of fastboot.
Signed-off-by: Jesse Barnes
---
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
b/drivers/gpu/drm/i915/intel_display.c
inde
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
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 12 insertio
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: Ch
From: Chris Wilson
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 need to reject the current
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
---
drivers/gpu/drm/i915/i915_drv.h |2
From: Chris Wilson
Signed-off-by: Chris Wilson
---
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 |9 +
drivers/gpu/drm/i915/intel_lvds.c
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
---
drivers/gpu/drm/i915/intel_display.c |7 --
drivers/gpu/drm/i915/intel_drv.h |7 ++
drivers
From: Chris Wilson
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 Wilson
---
drivers/gpu/drm
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 the
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.
>
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: https://bugs.freedesktop.org/show
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:
On Tuesday 26 of March 2013 16:49:30 Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb 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 used,
On Tue, Apr 02, 2013 at 03:48:09PM +0300, Jani Nikula wrote:
> No functional changes.
>
> Signed-off-by: Jani Nikula
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 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-che
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
Besides the panel code t
From: Ville Syrjälä
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 bit for
DP, we might as well
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/intel_display.c | 123 +++
1 file changed, 68 insertions
From: Ville Syrjälä
VLV has the color range selection bit in the PIPECONF register.
Configure it appropriately.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/d
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
With the previous work asle and gse interrupt handlers should now be
functionally the same. Drop the duplicated code.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_irq.c |4 ++--
drivers/gpu/drm/i915/intel_opregion.c | 37 ---
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
---
drivers/gpu/drm/i915/intel_opregion.c | 19
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
---
drivers/gpu/drm/i915/intel_opregion.c |4 +---
1 file changed, 1 insertion(+), 3 de
Backlight is fiddled both through backlight sysfs files and asle
interrupts. Protect the relevant data.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/intel_panel.c | 16
2 files changed, 17 insertions(+)
diff --git a/drivers/
No functional changes.
Signed-off-by: Jani Nikula
---
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 a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gp
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
drm/i915/
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
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h |2 ++
> drive
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
> ---
> drivers/gpu/drm/i915/intel_pm.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --g
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 compo
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
> 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 in mind. Would tha
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
Hi Daniel,
Daniel Vetter writes:
> On Fri, Mar 29, 2013 at 5:35 PM, Egbert Eich 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 again plea
85 matches
Mail list logo
