On 10/28/2013 04:09 PM, Jani Nikula wrote:
On Mon, 28 Oct 2013, Aaron Lu aaron...@intel.com wrote:
+static int __init video_set_use_native_backlight(const struct dmi_system_id
*d)
+{
+use_native_backlight = true;
+return 0;
+}
Hi Aaron, it might be beneficial to make
On Mon, Oct 28, 2013 at 01:46:39PM -0700, Jesse Barnes wrote:
Needed to support large panel resolutions.
Tested-by: Josh Triplett j...@joshtriplett.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
Embedded Dell motherboard/video BIOS has very limited VESA support!!!
(F00:80x25=VGA, F01:80x50=VGA, F02:80x43=VGA, F03:80x28=VGA, F05:80x30=VGA,
F07:80x60=VGA, 309:132x25=VESA, 30A:132x43=VESA, 30B:132x50=VESA,
30C:132x60=VESA, (8)120:132x25=BIOS, (8)121:132x43=BIOS, (8)122:132x50=BIOS,
On Tue, Oct 29, 2013 at 9:37 AM, Felix Miata mrma...@earthlink.net wrote:
Pre-KMS it used to be that common vga= modes were useless, so I took to
using 0x121 to escape from 80x25 screens. Using 0x8121 required specifying
an appropriate font via config file. Even after KMS began, vga=0x8121
On Mon, Oct 28, 2013 at 08:49:45AM +0100, Daniel Vetter wrote:
Hi Dave,
Please do _not_ pull this. The pipe bpp readout stuff this crucially
relies on is only partially backported from -next to -fixes and apparently
missing bits on Haswell.
Ok, updated pull request. I wanted to wait a bit
We really need this since otherwise the magic return value handling
for running testcases with piglit (or on QA's validation
infrastructure) doesn't work properly.
We need to be careful though to only install this check on success.
See also the previous commits to sprinkle igt_exit() calls over
Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual bug is when we change the state of an already
active pipe.
For example when we change the fdi lines from 2 to 3 without switching
off
On 2013-10-29 09:51 (GMT+0100) Daniel Vetter composed:
Felix Miata wrote:
Pre-KMS it used to be that common vga= modes were useless, so I took to
using 0x121 to escape from 80x25 screens. Using 0x8121 required specifying
an appropriate font via config file. Even after KMS began, vga=0x8121
On Tue, Oct 29, 2013 at 12:04:08PM +0100, Daniel Vetter wrote:
Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual bug is when we change the state of an already
active pipe.
For
On Tue, Oct 29, 2013 at 02:46:10PM +0200, Ville Syrjälä wrote:
On Tue, Oct 29, 2013 at 12:04:08PM +0100, Daniel Vetter wrote:
Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual
On Tue, Oct 29, 2013 at 08:00:20AM -0400, Felix Miata wrote:
On 2013-10-29 09:51 (GMT+0100) Daniel Vetter composed:
Felix Miata wrote:
Pre-KMS it used to be that common vga= modes were useless, so I took to
using 0x121 to escape from 80x25 screens. Using 0x8121 required specifying
an
On Tue, Oct 29, 2013 at 11:29:29AM +0100, Daniel Vetter wrote:
On Mon, Oct 28, 2013 at 08:49:45AM +0100, Daniel Vetter wrote:
Hi Dave,
Please do _not_ pull this. The pipe bpp readout stuff this crucially
relies on is only partially backported from -next to -fixes and apparently
missing
In
commit 6efdf354ddb186c6604d1692075421e8d2c740e9
Author: Imre Deak imre.d...@intel.com
Date: Wed Oct 16 17:25:52 2013 +0300
the check for i915_disable_power_well flag was removed by overlook,
so add it back now.
Reported-by: Paulo Zanoni paulo.zan...@intel.com
Signed-off-by: Imre Deak
On Mon, Oct 28, 2013 at 04:51:52PM -0200, Paulo Zanoni wrote:
2013/10/28 Imre Deak imre.d...@intel.com:
Similarly rename the other related functions in the power domain
interface.
Higher level driver code calling these functions knows only about power
domains, not the underlying power
From: Ville Syrjälä ville.syrj...@linux.intel.com
drm_calc_timestamping_constants() makes the math more complex
than necessary.
- multipying the dotclock by 1000 is pointless, just makes all the
numbers bigger
- div64_u64() is also pointless, div_u64 is enough
- pixeldur_ns doesn't need any
From: Ville Syrjälä ville.syrj...@linux.intel.com
We don't really use hwmode anymore in i915, so eliminating its use
from the core code seems prudent. Just pass the appropriate mode
to drm_calc_timestamping_constants().
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
The scanline counter counts lines in the current field, not the entire
frame. But the crtc_ timings are the values for the entire frame. Divide
the vertical timings by 2 to make them match the scanline counter.
The rounding was carefully chosen
From: Ville Syrjälä ville.syrj...@linux.intel.com
Update the pixel/line/frame duration information when we switch to the
new pipe config. This will keep the timestamping constants in better
sync with the real hardware state.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move the long blurp to into the body of the comment, leaving only
a short summary line at the top.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 13 ++---
1 file changed, 6 insertions(+), 7
From: Ville Syrjälä ville.syrj...@linux.intel.com
crtc_clock is now supposed to be the actual pixel clock corresponding to
the other crtc_ timing values. Populate crtc_clock appropriately in
radeon_atom_get_tv_timings().
This was the only obvious place where we frob with the crtc_ timigns
From: Ville Syrjälä ville.syrj...@linux.intel.com
We're currently miscalculating the line and pixel durations for
interlaced modes. crtc_htotal and crtc_vtotal are the full frame
timings, and so is crtc_clock, so we can compute the line
and pixel durations from those w/o any extra adjustments.
From: Ville Syrjälä ville.syrj...@linux.intel.com
drm_calc_timestamping_constants() computes the pixel/line/frame
durations based on the crtc_ timing values. The corresponding pixel
clock is in mode-crtc_clock, so we need to use that instead of
mode-clock.
This should fix
From: Ville Syrjälä ville.syrj...@linux.intel.com
On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as
far as display interrupts are concerned. Instead it sort of looks like
some ISR bits just directly reflect the corresponding bit from PIPESTAT.
The bit appears in the ISR only
From: Ville Syrjälä ville.syrj...@linux.intel.com
Preparation for moving the early vblank IRQ logic into
radeon_get_crtc_scanoutpos().
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_irq.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
From: Ville Syrjälä ville.syrj...@linux.intel.com
i915 doesn't need this kludge for most platforms. Although we do
appear to need something similar on certain platforms, but we can
be more accurate when we apply the adjustment since we know exactly
why the scanline counter doesn't always quite
From: Ville Syrjälä ville.syrj...@linux.intel.com
Using s64 for the timestamping constants is wasteful. Signed 32bit
integers get us a range of over +-2 seconds. Presuming that no-one
wants to a vrefresh rate less than 0.5, we can switch to using int
for the timestamping constants. We save a few
Hi all,
So in the past half year we've had tons of sometimes rather heated discussions
about getting patches merged. Often these discussions have been in the context
of specific patch series, which meant that people are already invested. Which
contributed to the boiling emotions. I'd like to
The bbstate contains useful bits of debugging information such as
whether the batch is being read from GTT or PPGTT, or whether it is
allowed to execute privileged instructions.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
On 10/27/2013 05:30 AM, Daniel Vetter wrote:
On Fri, Oct 25, 2013 at 06:42:35PM -0700, Ian Romanick wrote:
Since the Mesa merge window is closing soon, I'm finally getting back on
this. I've pushed a rebase of my old Mesa branch to my fd.o repo
Daniel Vetter dan...@ffwll.ch writes:
Hi Ben
So first things first: I rather like what the code looks like overall at
the end. I've done a light read-through (by far not a full review) and
besides a few bikesheds (all mentioned by mail already) the big thing is
the 1:1 context:ppgtt address
On 2013-10-29 13:54 (GMT+0100) Daniel Vetter composed:
Felix Miata wrote:
On 2013-10-29 09:51 (GMT+0100) Daniel Vetter composed:
Felix Miata wrote:
Pre-KMS it used to be that common vga= modes were useless, so I took to
using 0x121 to escape from 80x25 screens. Using 0x8121 required
On Tue, 29 Oct 2013 16:08:24 -0700
Eric Anholt e...@anholt.net wrote:
Daniel Vetter dan...@ffwll.ch writes:
Hi Ben
So first things first: I rather like what the code looks like overall at
the end. I've done a light read-through (by far not a full review) and
besides a few bikesheds
Since a number of people internally are also involved in i915
development but not on the mailing list, I think we'll need to have an
internal meeting or two to cover this stuff and get buy in.
Overall, developing tests along with code is a good goal. A few
comments below.
On Tue, 29 Oct 2013
On Wednesday, October 30, 2013 12:40:13 AM Matthew Garrett wrote:
On Wed, 2013-10-16 at 01:33 +0200, Rafael J. Wysocki wrote:
Since the next step will be to introduce a list of systems that need
video.use_native_backlight=1 *and* don't break in that configuration, I
don't
see much
On Wed, 2013-10-16 at 01:33 +0200, Rafael J. Wysocki wrote:
Since the next step will be to introduce a list of systems that need
video.use_native_backlight=1 *and* don't break in that configuration, I don't
see much point adding another Kconfig option for the default.
I'd still really prefer
Incorrect definition DPIO_TX3_SWING_CTL4.
Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6799d53..f7ecad2
Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current
DPIO register definition doesn't have a structure way to break them
down. As a result it is not easy to match the PHY/PLL registers with the
configdb document. Rename those registers based on the configdb for easy
cross
vlv_dpio_read/write should be describe more in PHY centric instead of
display controller centric.
Create a enum dpio_channel for channel index and enum dpio_phy for PHY
index. This should better to gather for upcoming platform.
v2: Rebase the code based on
drm/i915/vlv: Fix typo in the DPIO
A change in locking of some kms drivers (currently intel-kms) make
the old approach too inaccurate and also incompatible with the
PREEMPT_RT realtime kernel patchset.
The driver-get_scanout_position() method of intel-kms now needs
to aquire a spinlock, which clashes badly with the former
Hi Dave,
this is v2 of the patch set for improving/restoring accuracy and
robustness of vblank timestamping and for fixing incompatibilities
with the PREEMPT_RT patches.
Could you please merge this for the next kernel? Would be good to have
the old accuracy restored as soon as possible. Thanks.
Move the ktime_get() clock readouts and potential preempt_disable()
calls from drm core into kms driver to make it compatible with the
api changes in the drm core.
The intel-kms driver needs to take the uncore.lock inside
i915_get_crtc_scanoutpos() and intel_pipe_in_vblank().
This is incompatible
Move the ktime_get() clock readouts and potential preempt_disable()
calls from drm core into kms driver to make it compatible with the
api changes in the drm core.
This should not introduce any change in functionality or behaviour
in radeon-kms, just a reshuffling of code.
Signed-off-by: Mario
Preemption handling will get pushed into the kms
drivers in followup patches, to make timestamping
more robust and PREEMPT_RT friendly.
Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Alex Deucher
43 matches
Mail list logo
