-gfx@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=No
uveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=mario.
kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART;VALUE=DATE:20231017
DTEND;VALUE=DATE:20231020
DTSTAMP:20230417T170311Z
ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com
UID:65qeuuc9e0gll25tq
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
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 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 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
>> >
>
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
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
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
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
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
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
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
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 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 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 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 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 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: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
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
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 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
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 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
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..
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
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
>> >
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/
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
, 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
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
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/
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
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
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
, 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
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
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
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
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
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
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
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
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
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
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ä
and
everything is fine now - No banding on the 6 bpc panel, no banding or
equipment failure on the external 8 bpc output. Life is good again :)
Reviewed-and-tested-by: Mario Kleiner
thanks,
-mario
Cc: Mario Kleiner
Reported-by: Mario Kleiner
Signed-off-by: Daniel Vetter
---
drive
On 08/07/2015 09:14 AM, Daniel Vetter wrote:
On Fri, Aug 07, 2015 at 12:45:52AM +0200, Mario Kleiner wrote:
On 08/07/2015 12:12 AM, Daniel Vetter wrote:
On Thu, Aug 6, 2015 at 11:56 PM, Mario Kleiner
wrote:
Hi Daniel and all,
since Linux 4.2 (tested with rc4), i think this commit
On 08/07/2015 12:12 AM, Daniel Vetter wrote:
On Thu, Aug 6, 2015 at 11:56 PM, Mario Kleiner
wrote:
Hi Daniel and all,
since Linux 4.2 (tested with rc4), i think this commit
d328c9d78d64ca11e744fe227096990430a88477
"drm/i915: Select starting pipe bpp irrespective or the primary plane&quo
Hi Daniel and all,
since Linux 4.2 (tested with rc4), i think this commit
d328c9d78d64ca11e744fe227096990430a88477
"drm/i915: Select starting pipe bpp irrespective or the primary plane"
causes trouble for me and my users, as tested on Intel HD Ironlake and
Ivy Bridge with MiniDP->Singlelink-D
On 05/29/2015 07:35 PM, Daniel Vetter wrote:
On Fri, May 29, 2015 at 07:23:35PM +0200, Mario Kleiner wrote:
On 05/29/2015 07:19 PM, Daniel Vetter wrote:
On Fri, May 29, 2015 at 06:50:06PM +0200, Mario Kleiner wrote:
On 05/27/2015 11:04 AM, Daniel Vetter wrote:
In
commit
On 05/29/2015 07:19 PM, Daniel Vetter wrote:
On Fri, May 29, 2015 at 06:50:06PM +0200, Mario Kleiner wrote:
On 05/27/2015 11:04 AM, Daniel Vetter wrote:
In
commit 9cba5efab5a8145ae6c52ea273553f069c294482
Author: Mario Kleiner
Date: Tue Jul 29 02:36:44 2014 +0200
drm/nouveau: Dis
On 05/27/2015 11:04 AM, Daniel Vetter wrote:
In
commit 9cba5efab5a8145ae6c52ea273553f069c294482
Author: Mario Kleiner
Date: Tue Jul 29 02:36:44 2014 +0200
drm/nouveau: Dis/Enable vblank irqs during suspend/resume
drm_vblank_on/off calls where added around suspend/resume to make sure
's no other way to figure out whether the crtc is
running. */
ret = drm_crtc_vblank_get(crtc[i]);
if (ret == 0) {
This one is
Reviewed-and-tested-by: Mario Kleiner
I was looking into Weston performance and the cursor problem, so had
necessary tracing in pl
On 05/15/2015 11:00 AM, Jani Nikula wrote:
On Fri, 15 May 2015, Mario Kleiner wrote:
Hi all,
since Linux 4.0 i experience some massive display flicker problem on my
Intel HD Ironlake mobile (2010 MacBookPro6,2) under Waylands reference
compositor Weston.
- Only happens on Linux >= 4.0
Hi all,
since Linux 4.0 i experience some massive display flicker problem on my
Intel HD Ironlake mobile (2010 MacBookPro6,2) under Waylands reference
compositor Weston.
- Only happens on Linux >= 4.0 on intel-kms with the Intel HD, not under
nouveau-kms with the discrete NVidia gpu. Strange
helper.
In that helper also assert that we do indeed hold
dev->vblank_time_lock, since in some cases the lock is acquired a
few functions up in the callchain.
Spotted while reviewing a patch from Chris Wilson to add a fastpath to
the vblank_wait ioctl.
Cc: Chris Wilson
Cc: Mario K
On 04/15/2015 03:03 AM, Mario Kleiner wrote:
On 04/02/2015 01:34 PM, Chris Wilson wrote:
On vblank instant-off systems, we can get into a situation where the cost
of enabling and disabling the vblank IRQ around a drmWaitVblank query
dominates. However, we know that if the user wants the
per also assert that we do indeed hold
dev->vblank_time_lock, since in some cases the lock is acquired a
few functions up in the callchain.
Spotted while reviewing a patch from Chris Wilson to add a fastpath to
the vblank_wait ioctl.
Cc: Chris Wilson
Cc: Mario Kleiner
Cc: Ville Syrjä
On 04/16/2015 03:29 AM, Peter Hurley wrote:
On 04/15/2015 05:26 PM, Mario Kleiner wrote:
A couple of questions to educate me and one review comment.
On 04/15/2015 07:34 PM, Daniel Vetter wrote:
This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need
g all callers and my point in extracting this little helper was
to localize all the locking into just one place. Hence I think that
additional optimization is too risky.
Cc: Chris Wilson
Cc: Mario Kleiner
Cc: Ville Syrjälä
Cc: Michel Dänzer
Cc: Peter Hurley
Signed-off-by: Daniel Vetter
---
d
on the first query following the IRQ.
Testcase: igt/kms_vblank
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 15 +--
1 file changed, 13 insertions(+), 2
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
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_
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
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
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
---
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
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
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
On 23/09/14 15:51, Daniel Vetter wrote:
On Tue, Sep 23, 2014 at 03:48:25PM +0300, Jani Nikula wrote:
On Mon, 15 Sep 2014, Daniel Vetter wrote:
On Sat, Sep 13, 2014 at 06:25:54PM +0200, Mario Kleiner wrote:
The current drm-next misses Ville's original Patch 14/19, the one i first
obj
e the timestamp with the latest estimate.
Testcase: igt/kms_flip/flip-vs-expired-vblank
Signed-off-by: Ville Syrjälä
Reviewed-by: Mario Kleiner
v2:Mario: Trivial rebase on top of current drm-next (13-Sep-2014)
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 3 +++
1 file changed,
On Wed, Sep 10, 2014 at 5:29 PM, Daniel Vetter wrote:
> On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
> wrote:
>> Hmm, not quite an ack from my side for the pull in its current form. I
>> said if the two remaining issues i mentioned are addressed, then i'm
>>
With these two fixes or similar applied i'd be happy, otherwise it
will inflict pain and real bugs on real users.
thanks,
-mario
On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
wrote:
> Hmm, not quite an ack from my side for the pull in its current form. I
> said if the two remainin
tory at:
>
> git://anongit.freedesktop.org/drm-intel tags/topic/vblank-rework-2014-09-10
>
> for you to fetch changes up to 2368ffb18b1d2b04eb80478d225676caa7a3c4c8:
>
> drm: Use vblank_disable_and_save in drm_vblank_cleanup() (2014-09-10
> 09:41:29 +0200)
>
>
I thought about this one again and opposed to my previous comment now think
it's fine, also for drivers without hw vblank counter queries.
-mario
On Wed, Aug 6, 2014 at 1:49 PM, wrote:
> From: Ville Syrjälä
>
> If we already have a timestamp for the current vblank counter, don't
> update it
nse if we would make that hook optional, allow a NULL
function pointer and adapt to the lack of that query, e.g., by never
disabling vblank irq's, except in drm_vblank_off() when a kms-driver
insists on disabling its irq during modeset/dpms off/suspend etc.
With these remarks somehow taken i
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
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:
> 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/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
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
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
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.
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
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
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
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 +++
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
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
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
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
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
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 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
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
1 - 100 of 125 matches
Mail list logo
