If test is running, irq_get was not called so we should
gain balance by not doing irq_put
v2: use local variable so it can't change during test (Chris)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/
Commit 094f9a54e355 ("drm/i915: Fix __wait_seqno to use true infinite
timeouts") added support for __wait_seqno to detect missing interrupts and
go around them by polling. As there is also timeout detection in
__wait_seqno, the polling and timeout detection were done with the same
timer.
When ther
Summary
We mainly focus the Q4 release testing these days, so this testing report
sending a little later.
We covered the platform: Broadwell, Baytrail-M, Haswell mobile, HSW desktop,
HSW ULT, IvyBridge, SandyBridge, IronLake.
In this circle, 10 new bugs are filed, 36 bugs are still opened, no WON
A bunch of packets were too short.
Signed-off-by: Kenneth Graunke
Cc: Ben Widawsky
Cc: Damien Lespiau
---
lib/rendercopy_gen8.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
The test is still broken for me, but I figure these patches are necessary
(if not s
We don't want depth/stencil fast clears or HiZ resolves; we want normal
drawing. Without this, the pixel pipeline doesn't work.
Signed-off-by: Kenneth Graunke
Cc: Ben Widawsky
Cc: Damien Lespiau
---
lib/gen8_render.h | 2 ++
lib/rendercopy_gen8.c | 10 ++
2 files changed, 12 inse
Basically check for both +ive and -ive deviation from target clock and
pick the one with minimal error. If we get a direct match, break from
loop to acheive some optimization.
v2: Use signed variable for target and calculated dsi clock values
Signed-off-by: Vijayakumar Balakrishnan
Signed-off-by
Hi All -
These patches enhance the current support for MIPI DSI for Baytrail. They
continue on the sub-encoder design and adds few more dev_ops to handle
sequence correctly. Major changes are -
1. DSI Clock calculation based on pixel clock
2. Add new dev_ops for better sequencing the enable/disabl
DSI PLL will get configured during crtc_enable using ->pre_pll_enable
and no need to do in ->mode_set
Signed-off-by: Shobhit Kumar
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/d
The values of these parameters will be different for differnet panel
based on dsi rate, lane count, etc. Remove the hardcodings and make
these as parameters whch will be initialized in panel specific
sub-encoder implementaion.
This will also form groundwork for planned generic panel sub-encoder
im
v2: Rebased on latest code
Signed-off-by: Shobhit Kumar
Signed-off-by: Yogesh Mohan Marimuthu
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_dsi.c | 47 ++-
Some panels require one time programming if they do not contain their
own eeprom for basic register initialization. The sequence is
Panel Reset --> Send OTP --> Enable Pixel Stream --> Enable the panel
v2: Based on review comments from Jani and Ville
- Updated the commit message with more det
Pixel clock based calculation is recommended in the MIPI host controller
documentation
v2: Based on review comments from Jani and Ville
- Use dsi_clk in KHz rather than converting in Hz and back to MHz
- RR formula is retained though not used but return dsi_clk in KHz now
- Moved the m
Basically ULPS handling during enable/disable has been moved to
pre_enable and post_disable phases. PLL and panel power disable
also has been moved to post_disable phase. The ULPS entry/exit
sequneces as suggested by HW team is as follows -
During enable time -
set DEVICE_READY --> Clear DEVICE_RE
On Tue, 2013-12-03 at 15:38 -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Don't try to set modes on two connectors that share the same encoder.
> That will just fail.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68463
> Signed-off-by: Paulo Zanoni
Looks ok:
Reviewed-by: Imr
hello,
is it normal that if I rule the brightness with xrandr, only the value
of gamma change and not the brightness ?
display actually becomes much clearer but this is due to gamma or
brightness ?
That is the question.
Thanks.
See you.
xrandr --output HDMI2 --brightness 1.20
xrandr --
hello,
is it normal that if I rule the brightness with xrandr, only the value of gamma
change and not the brightness ?
display actually becomes much clearer but this is due to gamma or brightness ?
That is the question.
Thanks.
See you.
xrandr --output HDMI2 --brightness 1.20
xrandr --verbo
On Mon, Dec 09, 2013 at 02:14:03PM +, S, Deepak wrote:
> >What precisely does this fix? All our register access is already wrapped in
> >get/put calls, so I'm a bit confused ... Is this to work around hw issues,
> >or is this what the bios expects when going into suspend?
>
> Yes Daniel, thi
From: Ville Syrjälä
Bruno Prémont has a 855 machine with a 1400x1050 LVDS screen.
The VBT mode is as follows:
0:"1400x1050" 0 108000 1400 1416 1528 1688 1050 1051 1054 1066 0x8 0xa
The BIOS uses the following DPLL settings:
DPLL = 0x9002
FP0 = 0x2140e
FP1 = 0x21207
We can't generate that p
There appear to be some gen2 machines that don't really like the current PLL
limits we have. We also have some accuracy problems with the PLL calculations.
This series aims to eliminate those problems, and at least my 855 machine
seems happier with these patches.
Ville Syrjälä (5):
drm/i915:
From: Ville Syrjälä
On my 855 machine the BIOS uses the following DPLL settings:
DPLL 0x90016000
FP0 = 0x61207
FP1 = 0x21207
With the 66MHz SSC refclock, that puts the BIOS generated VCO
frequency at ~908 MHz, which is lower than the 930 MHz limit
we have currently. This also results in the pixe
From: Ville Syrjälä
Store the SSC refclock frequency in kHz to get more accuracy. Currently
we're pretending that 66 MHz is ~66000 kHz, when in fact it is actually
~7 kHz. By storing the less rounded kHz value we get a much better
accuracy for out pixel clock calculations.
Cc: Bruno Prémont
From: Ville Syrjälä
Bruno Prémont has a 855 machine with a 1400x1050 LVDS screen.
The VBT mode is as follows:
0:"1400x1050" 0 108000 1400 1416 1528 1688 1050 1051 1054 1066 0x8 0xa
The BIOS uses the following DPLL settings:
DPLL = 0x9002
FP0 = 0x2140e
FP1 = 0x21207
That puts the BIOS gener
From: Ville Syrjälä
In order to determine the correct p2 divider for LVDS on gen2,
we need to check the CLKB mode from the LVDS port register to
determine if we're dealing with single or dual channel LVDS.
Cc: Bruno Prémont
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c
Hello,
I have a Dell L502x which have a optimus Graphic Pack:
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Dell Device 050e
Flags: bus master, fast devsel,
yeap... I sent the series one week earlier than I should.
Please just ignore this full -collector round.
On Mon, Dec 9, 2013 at 11:37 AM, Damien Lespiau
wrote:
> On Mon, Dec 09, 2013 at 10:42:58AM -0200, Rodrigo Vivi wrote:
>> From: Jani Nikula
>>
>> Checkpatch tells me
>>
>> WARNING: __packed
I am trying to get more details. I will update the thread once I have some
clarification. Thanks for reviewing.
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Monday, December 9, 2013 3:34 PM
To: S, Deepak
Cc: intel-gfx@lists.freedesktop.org
Subject:
> Have you actually seen cases where the BIOS would be buggy enough to lock the
> power context addres at 0? If so, we should just scream and run away instead
> of blindly trying to write a new address to PCBR and pretending that things
> are fine after that.
We had faced some issue doing the i
>What precisely does this fix? All our register access is already wrapped in
>get/put calls, so I'm a bit confused ... Is this to work around hw issues, or
>is this what the bios expects when going into suspend?
Yes Daniel, this was sequence recommended when going into suspend/Resume path.
Hi Chris,
My understanding is that running at efficient freq (RPe) where RPe is greater
than the min freq (RPn) (RPe > RPn), at same Vmin voltage should give us better
performance right?. Please correct me if my understand is not right
Thanks
Deepak
-Original Message-
From: Chris Wilso
On Mon, Dec 09, 2013 at 10:42:58AM -0200, Rodrigo Vivi wrote:
> From: Jani Nikula
>
> Checkpatch tells me
>
> WARNING: __packed is preferred over __attribute__((packed))
>
> so switch over to __packed across the driver before adding new packed
> structs.
>
> Signed-off-by: Jani Nikula
> Signe
From: Daniel Vetter
This way we'll catch bugs in our code where we depend upon pipe config
state not (yet) read out much quicker, through a simple dpms on/off
cycle.
This will blow up all over the place for now, hence just a quick idea
to toss out there.
Signed-off-by: Daniel Vetter
Signed-off
From: Daniel Vetter
So shuffle the checks around a bit. Also give all the structs and
functions proper prefixes: i830_ for the dual-pipe mobile platforms
and i845_ for the two single-pipe desktop platforms.
Note that the max fifo value isn't actually correct for the i830M, but
since we don't fro
From: Jani Nikula
Checkpatch tells me
WARNING: __packed is preferred over __attribute__((packed))
so switch over to __packed across the driver before adding new packed
structs.
Signed-off-by: Jani Nikula
Signed-off-by: Rodrigo Vivi
Reviewed-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: Asynchronously perform the set-base for a simple modeset -
Reviewed
Patch drm
From: Jani Nikula
We don't actually do anything with the information yet, but parse and
log what's in the VBT.
Signed-off-by: Jani Nikula
Signed-off-by: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_bios.c | 29 +++
From: Imre Deak
At least on my VLV stepping VGA detection doesn't work in certain cases.
One such case is when all pipes are off and VGA is plugged in. Another
case reported by Joonas Lahtinen (also on the same stepping) is booting
with VGA disconnected where we incorrectly report that VGA is con
From: Deepak S
On VLV, FIFO will be shared by both SW and HW. So, we read the
free entries through register and update dev_priv variable
and wait for only 20 entries to be free
v2: Apply mask when we read the number of free FIFO entries (Ville).
v3: Mask applied after reading the register (Deep
From: Chris Wilson
If we force the hw to idle as our first step during unload, we can abort
the unload upon failure. Later we can probe whether the hardware remain
active even after we try to shut it down.
Signed-off-by: Chris Wilson
Reviewed-by: Rodrigo Vivi
Signed-off-by: Rodrigo Vivi
---
From: Chris Wilson
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
1. We need to make sure the fb->obj is in the display domain, which
incurs a cache flush to ensure no dirt is le
With the advent of hw context support, we gained some objects that are
pinned for the duration of their request. That is we can make aperture
space available by idling the GPU and in the process performing a
context switch back to the always-pinned default context. As such, we
should not conclude t
On Sun, Dec 08, 2013 at 02:16:45PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> When current delay is already at max delay, Let's disable the PM UP
> THRESHOLD INTRRUPTS, so that we will not get further interrupts until
> current delay is less than max delay, Also request for the PM DOWN
On Sun, Dec 08, 2013 at 02:16:43PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> on VLV, P-Unit doesn't garauntee that last requested freq by driver
> is actually the current running frequency. We need to make sure we update
> the cur freq. before requesitng new freq.
>
> Signed-off-by:
On Sun, Dec 08, 2013 at 01:52:35PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> On VLV the PCBR register has other bits besides the pcbr address
> field. Verify only address field setup by BIOS to make sure we don't
> misinterpret the PCBR setup.
>
> Signed-off-by: Deepak S
> ---
> dr
On Mon, 09 Dec 2013, Vandana Kannan wrote:
> If one mode of a internal panel has more than one refresh rate, then a reduced
> clock is found for the LFP (LVDS/eDP). This enables switching between low
> and high frequency dynamically. Moving downclock calculation to intel_panel
> so that it is comm
On Sun, Dec 08, 2013 at 02:16:46PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> Voltage is not getting dropped to Vmin when GFX enters RC6 and running
> in/out of turbo frequency. When we enter RC6 and GFX Clocks are off, the
> voltage remains higher than Vmin. As GFX does not request lo
On Sun, Dec 08, 2013 at 01:52:59PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> Since early sanitize and uncore sanitize are called one after the other,
> I think, we can remove second forcewake reset which was are calling
> twice in both the functions.
>
> Signed-off-by: Deepak S
Thi
If one mode of a internal panel has more than one refresh rate, then a reduced
clock is found for the LFP (LVDS/eDP). This enables switching between low
and high frequency dynamically. Moving downclock calculation to intel_panel
so that it is common for LVDS and eDP.
Signed-off-by: Vandana Kannan
On Sun, Dec 08, 2013 at 02:16:45PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> When current delay is already at max delay, Let's disable the PM UP
> THRESHOLD INTRRUPTS, so that we will not get further interrupts until
> current delay is less than max delay, Also request for the PM DOWN
On Sun, Dec 08, 2013 at 01:52:46PM +0530, deepa...@intel.com wrote:
> From: Deepak S
>
> Instead of waiting for HW to bringup the wells, We force the wells up
> before disabling RC6. This is to avoid any register access when wells
> are down.
>
> Signed-off-by: Deepak S
> ---
> drivers/gpu/drm
49 matches
Mail list logo
