On Thu, Jun 10, 2021 at 9:55 AM Pekka Paalanen wrote:
>
> On Tue, 8 Jun 2021 19:43:15 +0200
> Werner Sembach wrote:
>
> > Add a new general drm property "active bpc" which can be used by graphic
> > drivers
> > to report the applied bit depth per pixel back to userspace.
> >
Maybe "bit depth p
On Mon, Oct 15, 2018 at 6:21 PM Ville Syrjälä
wrote:
> On Tue, Jun 12, 2018 at 06:20:35PM +0200, Mario Kleiner wrote:
> > The various clut handling functions like a setup
> > consistent with the x-screen color depth. Otherwise
> > we observe improper sampling in the gamma t
On Fri, Apr 26, 2019 at 6:32 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Generalize the code that parses the plane properties to be useable
> for crtc (or any kms object) properties as well.
>
> v2: plane 'type' prop is enum not range!
>
> Cc:
On Fri, Apr 26, 2019 at 6:32 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Probe the GAMMA_LUT/GAMMA_LUT_SIZE props and utilize them when
> the running with > 8bpc.
>
> v2: s/sna_crtc_id/__sna_crtc_id/ in DBG since we have a sna_crtc
>
> Cc: Mario Kleiner
Since i pulled the current drm-next tree i see strong flicker and visual
corruption during pageflipping, both in my own app, but also in KDE4 and
KDE5 Plasma with desktop composition enabled. This happens on both Intel
HD Ironake mobile (Apple MBP 2010) and HD-4000 Ivybridge mobile (Apple
macMi
A strange one. In Linux 4.7-rc4, at least as build by the Ubuntu
mainline ppa, gamma table updates via RandR don't work. No errors are
reported and the X-Server thinks everything went well, but on Intel
Ironlake and Ivybridge the updates don't have any visual effect.
The same problem doesn't h
On 07/06/2016 03:05 PM, Chris Wilson wrote:
On Wed, Jul 06, 2016 at 12:17:55PM +0200, Mario Kleiner wrote:
Since i pulled the current drm-next tree i see strong flicker and
visual corruption during pageflipping, both in my own app, but also
in KDE4 and KDE5 Plasma with desktop composition
HD Ironlake to confirm the
fix apparently doesn't break anything under X11.
Signed-off-by: Mario Kleiner
Cc: Maarten Lankhorst
Cc: Lionel Landwerlin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/d
, the final rc afaik?
thanks,
-mario
Cheers,
-
Lionel
On 12/07/16 11:33, Mario Kleiner wrote:
Updating legacy gamma tables, e.g., via RandR doesn't work at all
as of Linux 4.7-rc6.
Reason seems to be that the required call to
drm_atomic_helper_commit_planes_on_crtc is skipped in
intel_ato
On 07/12/2016 05:02 PM, Lionel Landwerlin wrote:
On 12/07/16 13:11, Mario Kleiner wrote:
On 07/12/2016 12:50 PM, Lionel Landwerlin wrote:
Hi Mario,
Hi Lionel,
There was a couple of patch to fix this issue :
https://patchwork.freedesktop.org/series/5467/
https://patchwork.freedesktop.org
fixes it nicely. The patch currently applies cleanly to drm-fixes and
drm-next and is
Reviewed-and-tested-by: Mario Kleiner
When we are at it, could somebody please look at that updated series of
my Displayport color depth fixes ("EDID/DP fixes for proper bpc
detection of displays.&quo
t; > Cc: Daniel Vetter
> > Cc: Nicholas Kazlauskas
> > Cc: Leo Li
> > Cc: Harry Wentland
> > Cc: David Francis
> > Cc: Mario Kleiner
> > Cc: Bhawanpreet Lakha
> > Cc: Ben Skeggs
> > Cc: "Christian König"
> > Cc: Ilia Mirkin
t; 8bpc.
>
> v2: s/sna_crtc_id/__sna_crtc_id/ in DBG since we have a sna_crtc
> v3: Fix the vg "bluered" typo (Mario)
> This time I even build tested with vg support
>
> Cc: Mario Kleiner
> Signed-off-by: Ville Syrjälä
> Reviewed-and-tested-by:
On Tue, Dec 14, 2021 at 3:03 PM Sebastian Andrzej Siewior <
bige...@linutronix.de> wrote:
> From: Mike Galbraith
>
> Mario Kleiner suggest in commit
> ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into
> kms driver.")
>
> a spots w
On Fri, Feb 11, 2022 at 9:44 AM Sebastian Andrzej Siewior
wrote:
>
> On 2022-01-27 00:29:37 [+0100], Mario Kleiner wrote:
> > Hi, first thank you for implementing these preempt disables according to
> Hi Mario,
>
> > the markers i left long ago. And sorry for the rather l
full color
depth of the panel. With this commit, we can use firmware setting
and get the full 10 bpc advertised by the Retina panel.
Signed-off-by: Mario Kleiner
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/display/intel_dp.c | 23 +++
1 file changed, 23 insertions(+)
diff
On Thu, Jan 9, 2020 at 4:27 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the
On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > firmwa
On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher wrote:
> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> wrote:
> >
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link ra
On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 at 05:26:57PM
On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 at 05:30:05PM
On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher wrote:
> On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
> wrote:
> >
> > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher
> wrote:
> >>
> >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> >> wrote:
> &
On Fri, Jan 10, 2020 at 2:32 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 09:19:07PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 at 06:57:14PM
On Thu, Jan 9, 2020 at 10:26 PM Harry Wentland wrote:
>
>
> On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
>
> On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher wrote:
>
>> On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
>> wrote:
>> >
>> > On Th
rm-tip, as of 16-March-2020. Adapt
to new edid_quirks parameter of drm_dp_has_quirk().
Signed-off-by: Mario Kleiner
Tested-by: Mario Kleiner
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp.c | 11 +++
include/drm/drm_d
On Thu, Feb 11, 2021 at 1:29 PM Ville Syrjälä
wrote:
> On Thu, Jan 28, 2021 at 11:24:13AM -0800, Matt Roper wrote:
> > From: Nischal Varide
> >
> > If the panel is 12bpc then Dithering is not enabled in the Legacy
> > dithering block , instead its Enabled after the C1 CC1 pipe post
> > color spa
On Fri, Feb 19, 2021 at 4:22 AM Mario Kleiner
wrote:
>
>
> On Thu, Feb 11, 2021 at 1:29 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
>
>> On Thu, Jan 28, 2021 at 11:24:13AM -0800, Matt Roper wrote:
>> > From: Nischal Varide
>> >
>
link rate during
edp setup.
Link to previous discussion of a different attempted fix
with Ville and Jani:
https://patchwork.kernel.org/patch/11325935/
Signed-off-by: Mario Kleiner
Cc: Ville Syrjälä
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
drivers/gpu/drm/i915/di
link rate during
edp setup.
Link to previous discussion of a different attempted fix
with Ville and Jani:
https://patchwork.kernel.org/patch/11325935/
v2: Follow Jani's proposal of defining quirk_rates[] instead
of just appending 324000. This for better clarity.
Signed-off-by: Mario Klein
On Wed, Mar 4, 2020 at 4:32 PM Jani Nikula wrote:
>
> On Sat, 29 Feb 2020, Mario Kleiner wrote:
> > This fixes a problem found on the MacBookPro 2017 Retina panel.
> >
> > The panel reports 10 bpc color depth in its EDID, and the
> > firmware chooses link setting
Just as a comment, u8 for max_vfreq in struct drm_adaptive_sync_info
might be not very future proof?
I just read that ASUS announced a "TUF Gaming VG259QM" monitor which
seems to have an adaptive sync range of 48 Hz to 280 Hz, exceeding the
max 255 Hz of u8?
-mario
On Fri, Mar 6, 2020 at 4:02
u, Mar 01, 2018 at 02:20:48AM +0100, Mario Kleiner wrote:
>> > > > The various clut handling functions like a setup
>> > > > consistent with the x-screen color depth. Otherwise
>> > > > we observe improper sampling in the gamma tables
>> >
Hi,
finally here's an updated patch that for depth 30 now works on both
Server 1.20 with the full colormap + gamma table handling, and for
servers < 1.20 with the RandR gamma tables working fine and the colormap
processing skipped.
This one successfully tested on sna and uxa with both server 1.20
handling intact.
Tested on 1.19.6 and 1.20.0 to do the right thing.
Signed-off-by: Mario Kleiner
---
src/sna/sna_driver.c | 9 ++---
src/uxa/intel_driver.c | 6 +-
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/sna/sna_driver.c b/src/sna/sna_driver.c
index 2007e354..
t use drm_vblank_count_and_time.
Changes since v2:
- Don't return time of last vblank.
Changes since v3:
- Change pipe to unsigned int. (Ville)
- Remove unused documentation for tv_ret. (kbuild)
Cc: Mario Kleiner
Cc: Ville Syrjälä
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
count.
Cc: Mario Kleiner
Cc: Ville Syrjälä
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä #v4
Acked-by: David Airlie #irc, v4
---
Unfortunately WARN_ON(!dev->disable_vblank_immediate) doesn't work on gen2,
which is the reason this function is created. So I used
WARN_ON(!ge
Anyway, although i would have liked the stricter check and warning docs,
the v4 patch is ok with me:
Reviewed-by: Mario Kleiner
-mario
On 04/25/2016 08:32 AM, Maarten Lankhorst wrote:
This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the
I'm fine with it. I assume the function will only be used by kms
drivers, whose writers probably know when it is safe to call the
function, ie. what kind of potential quirks the kms drivers timestamping
implementation has.
Reviewed-by: Mario Kleiner
On 05/17/2016 03:07 PM, Maarten Lank
On 05/09/2016 08:11 PM, Daniel Vetter wrote:
On Mon, May 09, 2016 at 08:16:07PM +0300, Ville Syrjälä wrote:
On Mon, May 09, 2016 at 05:08:43PM +0100, Matthew Auld wrote:
This patch aims to replace the roll-your-own seqlock implementation with
full-blown seqlock'. We also remove the timestamp ri
he local irq disable. I'll give it a test
later this week.
Reviewed-by: Mario Kleiner
Indeed the old inactive @tuebingen.mpg.de is only a forward to the gmail
address, probably with some botched mail filter rules, so they can go
unnoticed quite
Hi,
so these two patches add i915 module parameters to globally override
how the driver handles dithering and gamma/csc conversion.
They serve two purposes: First as debug aid and "airbag" for working
around potential precision problems in getting pixels from rendering
to the display outputs. Thi
, to have an override
for DE's which may not expose such properties via some standard
protocol in a user-controllable way, e.g., afaik all currently
existing Wayland compositors.
Tested on Ironlake, IvyBridge, Haswell, Skylake.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/i915/i915_par
ll
restricts the effective output precision to 8 bit, while an
auto-bypassed precision lut doesn't restrict precision.
Iow. this patch is needed even with XR30 fb's for actual 10
bit precision output, even though the hw seems to sort of ignore
the tested gamma tables for XR30
On 09/26/2017 07:05 AM, Daniel Vetter wrote:
On Fri, Sep 15, 2017 at 05:48:25PM +0200, Mario Kleiner wrote:
The new module parameter enable_hw_color_correction defaults to
true, to retain the current behaviour. If set to false, it will
disable all hardware color correction, like gamma/degamma
aps().
Tested for uxa and sna at depths 8, 16, 24 and 30 on
IvyBridge, and tested at depth 24 and 30 that xgamma
and gamma table animations work, and with measurement
equipment to make sure identity gamma ramps actually
are identity mappings at the output.
Signed-off-by: Mario Kleiner
---
src/
following the wait completion.
However, if the user is simply querying the current vblank counter and
timestamp, the interrupt will be disabled after every IRQ and the user
will enabled it again on the first query following the IRQ.
v2: Mario Kleiner -
After testing this, one more thing that would make
Cc: Dave Airlie ,
Cc: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 5b77057e91ca..1d6bcee3708f 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/
On 29/11/13 14:36, Ville Syrjälä wrote:
On Wed, Nov 06, 2013 at 01:46:41PM +1000, Dave Airlie wrote:
On Wed, Oct 30, 2013 at 4:06 AM, wrote:
So I took another look at the vblank timestamping code, and got a bit
excited. The result is this patchset.
I'd like to merge this, I was hoping Mario
On 29/10/13 19:06, ville.syrj...@linux.intel.com wrote:
> 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 int
On 29/10/13 19:06, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Preparation for moving the early vblank IRQ logic into
radeon_get_crtc_scanoutpos().
Signed-off-by: Ville Syrjälä
Tiny compile fix needed for this one. The function prototype for
radeon_get_crtc_scanoutpos() is als
On 29/10/13 19:06, ville.syrj...@linux.intel.com wrote:
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 cou
What's the real issue here?
That the vblank timestamp needs to be an accurate measurement of a
realtime event. Sleeping/servicing interrupts while reading
the registers necessary to compute the timestamp would be bad too.
(edit: which hopefully Mario Kleiner clarified in hi
start or end of vblank. We can do that by double checking
the DSL value against the vblank status bit from ISR.
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 53 +
1 file changed, 53 insertions(+)
diff --git a
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM
On 24.09.13 11:11, Daniel Vetter wrote:
...
Hooray, this rips out the racy pipe_to_cpu_transcoder deref, so I'm all in
favour \o/ Of course I still have that ugly itme on my todo about "fix the
locking for kms vblank stuff" ;-)
See the other e-mail i sent. Maybe pushing the time read into th
way we'd ever call ->get_scanout_position(), we can
completely ignore UMS in i915_get_crtc_scanoutpos().
Also reorganize intel_irq_init() a bit to clarify the KMS vs. UMS
situation.
v2: Drop UMS code
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915
we should keep our numbers in the pixel count domain while we're
adjusting the position to be relative to vbl_end. Then when we do the
conversion in the end, both vertical _and_ horizontal components will
come out correct.
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/
On 25.09.13 10:14, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 04:35:56AM +0200, Mario Kleiner wrote:
On 23.09.13 13:48, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
We have all the information we need in the mode structure, so going and
reading it from the hardware is pointless
On 25.09.13 16:13, Steven Rostedt wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner wrote:
But given the new situation, your proposal is great! If we push the
clock readouts into the get_scanoutpos routine, we can make this robust
without causing grief for the rt people and without the
On 25.09.13 09:49, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 06:32:10AM +0200, Mario Kleiner wrote:
On 23.09.13 10:38, Ville Syrjälä wrote:
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter
On 25.09.13 10:11, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 05:12:54AM +0200, Mario Kleiner wrote:
On 23.09.13 12:02, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The DSL register increments at the start of horizontal sync, so it
manages to miss the entire active portion of
assignments in intel_irq_init() a
bit to avoid confusing people.
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
---
Just another small vblank related gem I forgot to polish up and send
out until Imre started asking me questions about the vblank counter
functions.
Hm, I've thought the magic
On 10/11/2013 03:30 PM, Sebastian Andrzej Siewior wrote:
On 10/11/2013 02:37 PM, Steven Rostedt wrote:
On Fri, 11 Oct 2013 12:18:00 +0200
Sebastian Andrzej Siewior wrote:
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I will do that. Thanks for clarifying the irq and constraints
on
vbl_end. So instead
we should keep our numbers in the pixel count domain while we're
adjusting the position to be relative to vbl_end. Then when we do the
conversion in the end, both vertical _and_ horizontal components will
come out correct.
Cc: Mario Kleiner
Signed-off-by: Vi
Yes.
On Oct 12, 2013 1:18 AM, "Daniel Vetter" wrote:
>
> On Fri, Oct 11, 2013 at 04:31:38PM +0200, Mario Kleiner wrote:
> > Daniel, Ville,
> >
> > i tested Ville's patch series for the scanoutpos improvements on a
> > GMA-950, on top of airlied's
Hi all,
this patch set for the kernel pushes the latency sensitive bits of
vblank scanoutpos timestamping from the drm core into the kms drivers.
A change in the locking of the intel-kms driver for Linux 3.11 made
the old approach too inaccurate and also incompatible with the
PREEMPT_RT realtime
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
---
drivers/gpu/drm/drm_irq.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu
sition ...
... no taking of locks allowed here! ...
if (etime) *etime = ktime_get();
preempt_enable_rt(); // On PREEMPT_RT kernel, otherwise omit.
spin_unlock...(...);
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 18 ++
include/drm/drmP.h| 10 +++
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
ng query retries.
After : Typically 1 usec (98% of all samples), occassionally 2 usecs
(2% of all samples), with maximum of 3 usecs (a handful).
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/i915/i915_irq.c | 53 +++
1 file changed, 42 insertions(+), 11 d
sition ...
... no taking of locks allowed here! ...
if (etime) *etime = ktime_get();
preempt_enable_rt(); // On PREEMPT_RT kernel, otherwise omit.
spin_unlock...(...);
v2: Fix formatting of new multi-line code comments.
Signed-off-by: Mario Kleiner
Reviewed-by: Ville Syrjälä
Reviewed-by: Alex D
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.
ng query retries.
After : Typically 1 usec (98% of all samples), occassionally 2 usecs
(2% of all samples), with maximum of 3 usecs (a handful).
v2: Fix formatting of new multi-line code comments.
Signed-off-by: Mario Kleiner
Reviewed-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers
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
Reviewed-by: Ville Syrjälä
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/drm_irq.c |7 ---
1 file changed, 7 deletions
--
Message: 5
Date: Tue, 2 Oct 2012 17:54:35 +0200
From: Daniel Vetter
To: Intel Graphics Development
Cc: Daniel Vetter , sta...@vger.kernel.org
Subject: [Intel-gfx] [PATCH 1/2] drm/i915: call drm_handle_vblank
before finish_page_flip
Message-ID: <134919327
On 02.10.12 20:08, Daniel Vetter wrote:
On Tue, Oct 2, 2012 at 7:45 PM, Mario Kleiner
wrote:
I'm fine with removing the hack and fixing this properly, especially if you
say that it didn't work realiably in some cases. But i hope this means that
timestamping sanity tests via flip_
Subject: Re: [RFC 4/4] drm: add support for raw monotonic vblank
timestamps
Message-ID: <1349446447.17758.73.camel@thor.local>
Content-Type: text/plain; charset="ISO-8859-1"
On Fre, 2012-10-05 at 16:59 +0300, Imre Deak wrote:
On Fri, 2012-10-05 at 15:55 +0200, Michel D?nzer wrote:
On
On 05.10.12 15:37, intel-gfx-requ...@lists.freedesktop.org wrote:
Today's Topics:
1. [RFC 0/4] drm: add raw monotonic timestamp support (Imre Deak)
2. [RFC 1/4] time: export getnstime_raw_and_real for DRM (Imre Deak)
3. [RFC 2/4] drm: make memset/calloc for _vblank_time more
Hi,
a series of three patches to improve the dri2 swap scheduling
and timestamping for the current intel ddx.
The first one enables proper OML_sync_control timestamping
while triple-buffering is enabled and XOrg 1.12+ with DRI2SwapLimit
support is in use. So far, timestamping was unuseable with
t
ple-buffering
is achieved by sacrificing OML_sync_control compliance, as in the
old implementation.
Tested against server without swaplimit api and 1.13 with swaplimit
api, both with and without triplebuffering enabled.
Signed-off-by: Mario Kleiner
---
src/intel_dri.c |
specs, except for the trivial case of a glXSwapBuffers call
with swap_interval == 1.
This small modification allows to keep the optimization in
the intended way, while removing the hilarious side effects
for timing sensitive applications.
Signed-off-by: Mario Kleiner
---
src/intel_dri.c | 22
gets unreliable and
tearing is present at the top of the screen due to lack of vsync.
Therefore no longer disable pageflipping if SwapBuffersWait is off.
Signed-off-by: Mario Kleiner
---
src/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel_displa
On 08.10.12 18:08, Eric Anholt wrote:
Daniel Vetter writes:
On Sun, Oct 07, 2012 at 08:38:07AM +0200, Mario Kleiner wrote:
Hi,
a series of three patches to improve the dri2 swap scheduling
and timestamping for the current intel ddx.
The first one enables proper OML_sync_control
On 08.10.12 13:35, Imre Deak wrote:
On Sat, 2012-10-06 at 03:41 +0200, Mario Kleiner wrote:
[...]
But then Psychtoolbox checks each timestamp it gets from somewhere
"outside" (OML_sync_control / INTEL_swap_events / ALSA audio timestamps,
network receive timestamps, evdev, x11, ...) i
On 23.10.12 20:53, Imre Deak wrote:
For measuring duration we want to avoid that our start/end timestamps
jump, so use monotonic instead of real time for that.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_irq.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
On 25.10.12 12:28, Imre Deak wrote:
On Thu, 2012-10-25 at 01:05 +0200, Mario Kleiner wrote:
On 23.10.12 20:53, Imre Deak wrote:
For measuring duration we want to avoid that our start/end timestamps
jump, so use monotonic instead of real time for that.
Signed-off-by: Imre Deak
---
drivers
On 30.10.12 19:33, Jesse Barnes wrote:
This lets us pass down flags the drivers might be interested in, e.g. async.
Signed-off-by: Jesse Barnes
Hi Jesse
I like it :) -- Anything that helps to get rid of the troublesome
'SwapBuffersWait' madness in the ddx at some point makes me happy.
di
On 31.10.12 19:51, Ville Syrjälä wrote:
On Wed, Oct 31, 2012 at 10:44:47AM -0700, Eric Anholt wrote:
Ville Syrjälä writes:
On Tue, Oct 30, 2012 at 01:33:47PM -0500, Jesse Barnes wrote:
The hw supports async flips through the render ring, so why not expose it?
It gives us one more "tear me
On 02.11.12 10:29, Ville Syrjälä wrote:
On Fri, Nov 02, 2012 at 05:45:29AM +0100, Mario Kleiner wrote:
On 31.10.12 19:51, Ville Syrjälä wrote:
On Wed, Oct 31, 2012 at 10:44:47AM -0700, Eric Anholt wrote:
Ville Syrjälä writes:
On Tue, Oct 30, 2012 at 01:33:47PM -0500, Jesse Barnes wrote
On 11.12.12 00:00, Jesse Barnes wrote:
On Mon, 10 Dec 2012 10:48:29 -0800
Jesse Barnes wrote:
On 15.10.12 16:52, Chris Wilson wrote:
> On Mon, 15 Oct 2012 16:46:52 +0200, Mario Kleiner
wrote:
>> Hi Chris,
>>
>> can you please check & merge at least the
On 10.12.12 19:48, Jesse Barnes wrote:
On 15.10.12 16:52, Chris Wilson wrote:
> On Mon, 15 Oct 2012 16:46:52 +0200, Mario Kleiner
wrote:
>> Hi Chris,
>>
>> can you please check & merge at least the first two patches of the
>> series into the intel d
On 03/18/2015 10:30 AM, Chris Wilson wrote:
On Wed, Mar 18, 2015 at 11:53:16AM +0900, Michel Dänzer wrote:
drm_vblank_count_and_time() doesn't return the correct sequence number
while the vblank interrupt is disabled, does it? It returns the sequence
number from the last time vblank_disable_and_
On 03/19/2015 04:04 PM, Ville Syrjälä wrote:
On Thu, Mar 19, 2015 at 03:33:11PM +0100, Daniel Vetter wrote:
On Wed, Mar 18, 2015 at 03:52:56PM +0100, Mario Kleiner wrote:
On 03/18/2015 10:30 AM, Chris Wilson wrote:
On Wed, Mar 18, 2015 at 11:53:16AM +0900, Michel Dänzer wrote
Hi,
an updated set of patches to fix the bugs i found in the
xserver dri3/present implementation and one bug in intel-ddx
uxa/dri3/present implementation. Axel Davys comments made me
rethink my original xserver patch and the new solution is
simple and better and afaics how this was actually intend
extension, makes debugging quite a bit more
easy.
Please also cherry-pick this for a 1.16.x stable update.
Signed-off-by: Mario Kleiner
---
present/present.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/present/present.c b/present/present.c
index ac9047e..e5d3fd5 100
Make sure we reject async flips if we don't support
async flips.
Signed-off-by: Mario Kleiner
---
src/uxa/intel_present.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/uxa/intel_present.c b/src/uxa/intel_present.c
index d20043f..d2aa9ee 100644
--- a/src/uxa/intel_present.c
Org 1.17 and XOrg 1.16.2 stable.
Applying on top of XOrg 1.16.2 may require cherry-picking
commit 2051514652481a83bd7cf22e57cb0fcd40333f33
which trivially fixes lack of support for protocol option
PresentOptionCopy - get two bug fixes for the price of one!
Signed-off-by: Mario Kleiner
---
On 12/05/2014 12:56 AM, Eric Anholt wrote:
Mario Kleiner writes:
Pageflips for Pixmap presents were not synchronized to vblank on
drivers with support for PresentCapabilityAsync, due to some
missing init for vblank->sync_flips. The PresentOptionAsync
flag was completely ignored
drm_events() function.
Fixes fdo bug #84744 on older kernels.
Signed-off-by: Mario Kleiner
---
src/sna/sna_display.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 163..a7ad6cc 100644
--- a/src/sna/sna_displ
1 - 100 of 125 matches
Mail list logo
