-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
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 spot
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
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
m-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_dp_hel
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 Kleiner
T
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 a
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 a
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 a
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 lin
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
> > > fir
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
: 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: Mario Klei
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
3)
>> > > On Thu, 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 table
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 <mario.k
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 <mario.kleiner...@gmail.com>
---
d
ts 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 fb's.
Signed-off-b
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.
ntel.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
Cc: Michel Dänzer <mic...@daenzer.net>
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: Dave Airlie <airl...@redhat.com>,
Cc: Mario Kleiner <mario.kleiner...@gmail.com>
---
drivers/gpu/drm/drm_irq.c | 18
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
it nicely. The patch currently applies cleanly to drm-fixes and
drm-next and is
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner...@gmail.com>
When we are at it, could somebody please look at that updated series of
my Displayport color depth fixes ("EDID/DP fixes for
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_atomic_commit
Ironlake to confirm the
fix apparently doesn't break anything under X11.
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Cc: Lionel Landwerlin <lionel.g.landwer...@intel.com>
Cc: Daniel Vetter <daniel.vet...@ffwll
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
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
. I'll give it a test
later this week.
Reviewed-by: Mario Kleiner <mario.kleiner...@gmail.com>
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 a while.
thanks,
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
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 <mario.kleiner...@gmail.com>
On 05/1
Anyway, although i would have liked the stricter check and warning docs,
the v4 patch is ok with me:
Reviewed-by: Mario Kleiner <mario.kleiner...@gmail.com>
-mario
On 04/25/2016 08:32 AM, Maarten Lankhorst wrote:
This function is useful for gen2 intel devices which have no frame
c
: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com> #v4
Acked-by: David Airlie <airl...@linux.ie&g
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 <mario.kleiner...@gmail.com>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
panel, 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 mario.kleiner...@gmail.com
thanks,
-mario
Cc: Mario Kleiner mario.kleiner...@gmail.com
Reported-by: Mario
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
mario.kleiner...@gmail.com wrote:
Hi Daniel and all,
since Linux 4.2 (tested with rc4), i
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-DVI
On 08/07/2015 12:12 AM, Daniel Vetter wrote:
On Thu, Aug 6, 2015 at 11:56 PM, Mario Kleiner
mario.kleiner...@gmail.com wrote:
Hi Daniel and all,
since Linux 4.2 (tested with rc4), i think this commit
d328c9d78d64ca11e744fe227096990430a88477
drm/i915: Select starting pipe bpp irrespective
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/27/2015 11:04 AM, Daniel Vetter wrote:
In
commit 9cba5efab5a8145ae6c52ea273553f069c294482
Author: Mario Kleiner mario.kleiner...@gmail.com
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
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 mario.kleiner...@gmail.com
Date: Tue Jul 29 02:36:44 2014 +0200
)
+ continue;
+
/* There'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 mario.kleiner...@gmail.com
I
On 05/15/2015 11:00 AM, Jani Nikula wrote:
On Fri, 15 May 2015, Mario Kleiner mario.kleiner...@gmail.com 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
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.
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 ch...@chris-wilson.co.uk
Cc: Mario Kleiner
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
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 ch...@chris-wilson.co.uk
Cc: Mario Kleiner mario.kleiner...@gmail.com
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
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 ch...@chris-wilson.co.uk
Cc: Mario Kleiner mario.kleiner...@gmail.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Michel Dänzer mic
Airlie airl...@redhat.com,
Cc: Mario Kleiner mario.kleiner...@gmail.com
---
drivers/gpu/drm/drm_irq.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c8a34476570a..6f5dc18779e2 100644
--- a/drivers
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
() function.
Fixes fdo bug #84744 on older kernels.
Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
---
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
On 12/05/2014 12:56 AM, Eric Anholt wrote:
Mario Kleiner mario.kleiner...@gmail.com 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
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
quite a bit more
easy.
Please also cherry-pick this for a 1.16.x stable update.
Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
---
present/present.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/present/present.c b/present/present.c
index ac9047e..e5d3fd5
Make sure we reject async flips if we don't support
async flips.
Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
---
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
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 mario.kleiner
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 dan...@ffwll.ch 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
to update the timestamp with the latest estimate.
Testcase: igt/kms_flip/flip-vs-expired-vblank
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Mario Kleiner mario.kleiner...@gmail.com
v2:Mario: Trivial rebase on top of current drm-next (13-Sep-2014)
Signed-off-by: Mario
:41:29 +0200)
Mario Kleiner (2):
drm: Remove drm_vblank_cleanup from drm_vblank_init error path.
drm: Use vblank_disable_and_save in drm_vblank_cleanup()
Ville Syrjälä (16):
drm: Always reject drm_vblank_get
, otherwise it
will inflict pain and real bugs on real users.
thanks,
-mario
On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
mario.kleiner...@gmail.com 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
On Wed, Sep 10, 2014 at 5:29 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Wed, Sep 10, 2014 at 4:19 PM, Mario Kleiner
mario.kleiner...@gmail.com 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
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, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
If we already have a
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 into account you have my
Reviewed-by: Mario Kleiner mario.kleiner...@gmail.com
for the whole series, if you want.
thanks,
-mario
On 08/06
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 interlaced
On 29/10/13 19:06, ville.syrj...@linux.intel.com wrote:
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
Tiny compile fix needed for this one. The
On 29/10/13 19:06, ville.syrj...@linux.intel.com wrote:
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
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, 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.
I'd like to
...
... 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 mario.kleiner...@gmail.com
Reviewed-by: Ville Syrjälä
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.
.
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 mario.kleiner...@gmail.com
Reviewed-by: Ville Syrjälä ville.syrj
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 alexander.deuc
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 mario.kleiner...@gmail.com
---
drivers/gpu/drm/drm_irq.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu
...
... 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 mario.kleiner...@gmail.com
---
drivers/gpu/drm/drm_irq.c | 18 ++
include/drm/drmP.h
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
.
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 mario.kleiner...@gmail.com
---
drivers/gpu/drm/i915/i915_irq.c | 53 +++
1 file changed, 42
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 bige...@linutronix.de wrote:
* Mario Kleiner | 2013-09-26 18:16:47 [+0200]:
Good! I will do that. Thanks for clarifying the irq
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 mario.klei...@tuebingen.mpg.de
Signed-off-by: Ville Syrjälä
Yes.
On Oct 12, 2013 1:18 AM, Daniel Vetter dan...@ffwll.ch 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 current drm-next branch.
There's one issue
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ä ville.syrj...@linux.intel.com
We have all the information we need in the mode structure, so going and
reading
On 25.09.13 16:13, Steven Rostedt wrote:
On Wed, 25 Sep 2013 06:32:10 +0200
Mario Kleiner mario.klei...@tuebingen.mpg.de 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
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 124 matches
Mail list logo
