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
Reviewed-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/drm_irq.c |7 ---
1 file changed, 7 deletions(-)
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 Kl
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.
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
preempt_
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 regis
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 refer
Incorrect definition DPIO_TX3_SWING_CTL4.
Signed-off-by: Chon Ming Lee
---
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 100644
--- a/drivers/gpu/d
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 prefe
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
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 20:
On Tue, 29 Oct 2013 16:08:24 -0700
Eric Anholt wrote:
> Daniel Vetter 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 ma
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 require
Daniel Vetter 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 space rel
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
>>
>> http://cgit.freedesktop.org/~idr/mesa/l
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
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 2
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 avoid
From: Ville Syrjälä
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 bytes in drm_crtc and
avoid a
From: Ville Syrjälä
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 match the vblank
status.
Also t
From: Ville Syrjälä
Preparation for moving the early vblank IRQ logic into
radeon_get_crtc_scanoutpos().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_irq.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
drivers/gpu/drm/radeon/radeon_display.c | 7 ---
driver
From: Ville Syrjälä
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 if the PIPESTAT interrupt is e
From: Ville Syrjälä
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 drm_calc_timestamping_constants() for frame packing
From: Ville Syrjälä
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. But
we actually want framedur_ns
From: Ville Syrjälä
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
directly instead of calling drm_mode
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/intel_display.c | 17 -
1 fil
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/drm_irq.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/driver
From: Ville Syrjälä
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 to make it do the right thing w
From: Ville Syrjälä
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 64bit math
Signed-off-by: Ville
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/drm_crtc_helper.c| 2 +-
drivers/gpu/drm/drm_irq.c
So I took another look at the vblank timestamping code, and got a bit
excited. The result is this patchset.
Summary of changes:
- kill crtc->hwmode dependency
- eliminate a bunch of 64bit math
- fix timestamps for stereo and interlaced modes (on i915 at least)
- move the "early vbl irq" hack into
From: Ville Syrjälä
drm core no longer uses crtc->hwmode, and neither does i915, so we can totally
ignore it
in i915.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
From: Ville Syrjälä
Rather than using crtc->hwmode, just pass the relevant mode to
drm_calc_vbltimestamp_from_scanoutpos(). This removes the last hwmode
usage from core drm.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_irq.c | 6 +++---
drivers/gpu/drm/i915/i915_irq.c | 3
On Mon, Oct 28, 2013 at 04:51:52PM -0200, Paulo Zanoni wrote:
> 2013/10/28 Imre Deak :
> > 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 wells whic
In
commit 6efdf354ddb186c6604d1692075421e8d2c740e9
Author: Imre Deak
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
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1
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
>
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 specifyin
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 act
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.
>
> F
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
co
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 o
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 a
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 b
On Tue, Oct 29, 2013 at 9:37 AM, 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
> continued to work, an
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,
(8)123
On Mon, Oct 28, 2013 at 01:46:39PM -0700, Jesse Barnes wrote:
> Needed to support large panel resolutions.
>
> Tested-by: Josh Triplett
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 64
>
On 10/28/2013 04:09 PM, Jani Nikula wrote:
> On Mon, 28 Oct 2013, Aaron Lu 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 use_native_back
46 matches
Mail list logo
