On Thu, Feb 20, 2020 at 10:55:18AM +, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Let's just calculate the hsync rate on demand. No point in wasting
> > space storing it and ris
On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 21, 2020 at 12:43 PM Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Feb 21, 2020 at 01:32:29PM +0200, Jani Nikula wrote:
&
On Fri, Feb 21, 2020 at 06:16:57PM +0100, Daniel Vetter wrote:
> On Fri, Feb 21, 2020 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 21, 2020 at 05:40:31PM +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 21, 2020 at 03:42:56PM +0100, Daniel Vetter wrote:
> > > &
On Fri, Feb 21, 2020 at 06:27:22PM +0100, Sam Ravnborg wrote:
> Hi Ville.
>
> On Wed, Feb 19, 2020 at 10:35:41PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Store the timings (apart from the clock) as u16. The uapi mode
> > struct already
pclk);
> >
>
> This just caught my eye while browsing the patch.
> It looks like a backward way to get the clock.
Yep. I'll cook up a patch to switch this to ->clock.
>
> But patch is fine, it was just a drive-by comment.
>
> Whole patch is:
&g
On Fri, Feb 21, 2020 at 05:15:20PM +0100, Sam Ravnborg wrote:
> On Wed, Feb 19, 2020 at 10:35:43PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > gma500 needs 4 bits (to store a pixel multiplier) in the
> > mode->private_flags, i915 currently has three
On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> On 19.02.2020 21:35, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Get rid of mode->vrefresh and just calculate it on demand. Saves
> > a bit of space and avoids the cached value gettin
} else {
> + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> + }
>
> - return config->funcs->atomic_commit(state->dev, state, true);
> + return config->funcs->atomic_commit(state->dev, state, nonblocking);
> }
> EXPORT_SYMBOL(drm_atomic_nonblocking
On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote:
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
&g
On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> On 25.02.2020 12:21, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
On Tue, Feb 25, 2020 at 05:45:06PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> > On 25.02.2020 12:21, Ville Syrjälä wrote:
> > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> > >> On 19.02.2
sfer-Encoding: 8bit
In-Reply-To:
X-Patchwork-Hint: comment
User-Agent: Mutt/1.10.1 (2018-07-13)
On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
> On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä
> wrote:
>
> > OK, so I went ahead a wrote a bit of cocci [1] to find the bad
On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> wrote:
> > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote:
>
> > > I have long suspected that a whole bunch of the "simple" displays
On Wed, Feb 26, 2020 at 03:56:36PM +0100, Linus Walleij wrote:
> On Wed, Feb 26, 2020 at 3:34 PM Ville Syrjälä
> wrote:
> > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote:
> > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrjälä
> > > wrote:
> > &g
de) {
> - /* We do not know the orientation, but their might be a quirk */
> drm_connector_set_panel_orientation_with_quirk(connector,
> - DRM_MODE_PANEL_ORIENTATION_UNKNOWN,
> + dev_priv->vbt.orientation,
That's the non-DSI specific one I presume
or_each_detailed_block (Ville)
> * Make the drm_get_adaptive_sync_range function static (Harry, Jani)
> v2:
> * Change vmin and vmax to use u8 (Ville)
> * Dont store pixel clock since that is just a max dotclock
> and not related to VRR mode (Manasi)
>
> Cc: Ville Syrjälä
> Cc: Harry Wentland
the code when
'width % 2 && user' is true.
> + return -EINVAL;
> +
> + if (width > screen_info.orig_video_cols ||
> height > (screen_info.orig_video_lines * vga_default_font_height)/
> c->vc_font.height)
> /* let svgatextmode tinker with video timings and
> --
> 2.17.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Mar 03, 2020 at 10:30:14PM +0800, zhangxiaoxu (A) wrote:
>
>
> 在 2020/3/3 21:59, Ville Syrjälä 写道:
> > That doesn't match how vc_screenbuf_size is computed elsewhere. Also
> > a lot of places seem to assume that the screenbuf can be larger than
> > vga_
On Mon, Mar 02, 2020 at 11:40:07PM +0200, Vladimir Zapolskiy wrote:
> Hi Ville,
>
> On 3/2/20 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change t
On Mon, Mar 02, 2020 at 10:47:13PM +0100, Sam Ravnborg wrote:
> Hi Ville.
>
> On Mon, Mar 02, 2020 at 10:34:19PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > A lot of the panel drivers put bogus looking values into
> > mode.clock. This seri
On Tue, Mar 03, 2020 at 07:36:35AM +0800, Icenowy Zheng wrote:
>
>
> 于 2020年3月3日 GMT+08:00 上午4:34:22, Ville Syrjala
> 写到:
> >From: Ville Syrjälä
> >
> >The currently listed dotclock disagrees with the currently
> >listed vrefresh rate. Change the dotclock t
On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> Hi Ville,
>
> On 20-03-02 22:34, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to mat
On Tue, Mar 03, 2020 at 01:10:26PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > The currently listed dotclocks disagree with the currently
> > listed vrefresh rates. Change th
On Mon, Mar 02, 2020 at 10:24:14PM +0100, H. Nikolaus Schaller wrote:
> Hi Ville,
>
> > Am 02.03.2020 um 21:34 schrieb Ville Syrjala
> > :
> >
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed
nt;
> > break;
> > + }
> > case SPEAKER_BLOCK:
> > /* Speaker Allocation Data Block */
> > if (dbl >= 1)
> >
>
> --
> Kees Cook
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
lines of:
"pixel [31:30 A][29:20 R][19:10 G][9:0 B]
byte [3][2][ 1 ][ 0 ]"
Though the mismathed proportions make it rather ugly.
Maybe we should even show the bit numbers for each component along
with everything else:
"component [1 A 0][9 R 4..3 R 0][9 G 6..5 G 0][9 B 8..7 B 0]
pixel [31 A 30][29 R 24..23 R 20][19 G 16..15 G 10][9 B 8..7 B 0]
byte [ 3][ 2][ 1 ][ 0 ]"
Could stretch the bytes to uniform size I guess. But still not entirely
readable :(
Anyways, ideas for an actually good way to docuement formats welcome...
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Mar 04, 2020 at 09:36:06AM -0800, Manasi Navare wrote:
> On Tue, Mar 03, 2020 at 03:42:12PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 02, 2020 at 04:08:59PM -0800, Manasi Navare wrote:
> > > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> &g
ed;
> + }
> out:
> drm_dp_mst_topology_put_port(port);
> return ret;
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> On Thu, 2020-03-05 at 15:11 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> > > It's next to impossible for us to do connector probing on topologies
> > >
On Thu, Mar 05, 2020 at 08:41:43PM +0100, H. Nikolaus Schaller wrote:
>
> > Am 03.03.2020 um 16:49 schrieb H. Nikolaus Schaller :
> >
> > Hi,
> >
> >> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä
> >> :
> >>
> >>> I have
On Fri, Mar 06, 2020 at 09:02:57AM +0100, Marco Felsch wrote:
> On 20-03-03 16:52, Ville Syrjälä wrote:
> > On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > > Hi Ville,
> > >
> > > On 20-03-02 22:34, Ville Syrjala wrote:
> > > > Fro
reaches drm-next bothers me.
It doesn't special case Intel repos. It just merges all the repos listed
in the config file to create a new drm-tip. There are Intel repos,
AMD repos, and various other repos. The point is to keep drm-tip always
up to date and working (*). And if you manage to create a conflict you
can't solve you can always ping someone who can. Also hoefully no one
should be seeing all that many conflicts due to rerere (unless you
actually created a new conflict that is).
* why would anyone run anything else but drm-tip anyway? ;)
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Mar 09, 2020 at 11:43:33PM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> On Mon, Mar 09, 2020 at 11:22:51PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 09, 2020 at 10:29:42PM +0200, Laurent Pinchart wrote:
> > > On Mon, Mar 09, 2020 at 08:45:41PM +0100, Sam Ravnbo
On Tue, Mar 10, 2020 at 08:05:32AM +0100, Marco Felsch wrote:
> On 20-03-09 15:18, Ville Syrjälä wrote:
> > On Fri, Mar 06, 2020 at 09:02:57AM +0100, Marco Felsch wrote:
> > > On 20-03-03 16:52, Ville Syrjälä wrote:
> > > > On Tue, Mar 03, 2020 at 08:33:20AM +0100, Ma
,
> + .hsync_start = 480 + 40,
> + .hsync_end = 480 + 40 + 10,
> + .htotal = 480 + 40 + 10 + 40,
> .vdisplay = 640,
> .vsync_start = 640 + 4,
> - .vsync_end = 640 + 4 + 3,
> - .vtotal = 640 + 4 + 3 + 4,
> + .vsync_end = 640 + 4 +
*/
> uint32_t cursor_width, cursor_height;
>
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 3f396d94afe4..2bc665cc6071 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -35,6 +35,11 @@ struct drm_crtc;
> struct drm_pr
return plane;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f45b5e86ec63..34923b1c284c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7212,6 +7212,7 @@ enum {
> #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
> #define PS_FILTER_MASK (3 << 23)
> #define PS_FILTER_MEDIUM (0 << 23)
> +#define PS_FILTER_PROGRAMMED (1 << 23)
> #define PS_FILTER_EDGE_ENHANCE (2 << 23)
> #define PS_FILTER_BILINEAR (3 << 23)
> #define PS_VERT3TAP(1 << 21)
> --
> 2.23.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
IPE(pipe, \
> + _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A), \
> + _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B))
Please parametrize by 'set' as well.
> +
> /* legacy palette */
> #define _LGC_PALETTE_A
; }
>
> - hscale = drm_rect_calc_hscale(&plane_state->uapi.src,
> - &plane_state->uapi.dst,
> - 0, INT_MAX);
> - vscale = drm_rect_calc_vscale(&plane_state->uapi.src,
> - &plane_state->uapi.dst,
> - 0, INT_MAX);
> + drm_rect_init(&dst, crtc_x, crtc_y, crtc_w, crtc_h);
Drop as well.
> + hscale = drm_rect_calc_hscale(&plane_state->uapi.src, &dst, 0, INT_MAX);
> + vscale = drm_rect_calc_vscale(&plane_state->uapi.src, &dst, 0, INT_MAX);
>
> /* TODO: handle sub-pixel coordinates */
> if (intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier) &&
> --
> 2.23.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Mar 09, 2020 at 02:39:39PM -0700, Manasi Navare wrote:
> This patch adds defines for the detailed monitor
> range flags as per the EDID specification.
>
> v2:
> * Rename the flags with DRM_EDID_ (Jani N)
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
&g
ince that is just a max dotclock
> and not related to VRR mode (Manasi)
>
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Clinton A Taylor
> Cc: Kazlauskas Nicholas
> Signed-off-by: Manasi Navare
> Reviewed-by: Nicholas Kazlauskas
> ---
> driver
for everyone
but I guess not.
>
> Cc: Ville Syrjälä
> Cc: Manasi Navare
> Cc: "Lee, Shawn C"
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 22 +++--
> 1 file changed, 20 insertions(+), 2 deleti
ister/unregister() from
> intel_dp_mst_connector_late_register/unregister() so we don't lose
> error injection - Ville Syrjälä
>
> Cc: Ville Syrjälä
> Cc: Manasi Navare
> Cc: "Lee, Shawn C"
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/di
nd = 800 + 209 + 1,
> > + .htotal = 800 + 209 + 1 + 45,
> > + .vdisplay = 480,
> > + .vsync_start = 480 + 22,
> > + .vsync_end = 480 + 22 + 1,
> > + .vtotal = 480 + 22 + 1 + 22,
> > + .vrefresh = 60,
> > +};
>
> Please adjust so:
> vrefres
ust DP (Nicholas)
> > * Use drm_for_each_detailed_block (Ville)
> > * Make the drm_get_adaptive_sync_range function static (Harry, Jani)
> > v2:
> > * Change vmin and vmax to use u8 (Ville)
> > * Dont store pixel clock since that is just a max dotclock
> > and not re
ister/unregister() from
> intel_dp_mst_connector_late_register/unregister() so we don't lose
> error injection - Ville Syrjälä
> Changes since v2:
> * Don't forget to clean up if intel_connector_register() fails - Ville
>
> Cc: Ville Syrjälä
> Cc: Manasi Nav
ruct intel_digital_port
> *intel_dig_port)
> intel_dig_port->set_infoframes = g4x_set_infoframes;
> intel_dig_port->infoframes_enabled = g4x_infoframes_enabled;
> } else if (HAS_DDI(dev_priv)) {
> - if (intel_dig_port->lspcon.active) {
>
On Sat, Mar 07, 2020 at 03:40:11PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > The currently listed dotclocks disagree with the currently
> > listed vrefresh rates. Change th
On Tue, Mar 03, 2020 at 06:24:25AM +0100, Heiko Schocher wrote:
> Hello Ville Syrjala,
>
> Am 02.03.2020 um 21:34 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change t
On Mon, Mar 09, 2020 at 04:33:19PM +0100, Linus Walleij wrote:
> On Mon, Mar 9, 2020 at 2:36 PM Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > The dotclock is three orders of magnitude out. Fix it.
> >
> > v2: Just set it to 20MHz (Linus)
On Tue, Mar 03, 2020 at 07:00:12AM -0600, Adam Ford wrote:
> On Mon, Mar 2, 2020 at 2:36 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to
On Mon, Mar 09, 2020 at 04:33:56PM +0100, Linus Walleij wrote:
> On Mon, Mar 9, 2020 at 2:38 PM Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > The listed dotclocks are two orders of mangnitude out.
> > Fix them.
> >
> > v2: Just divid
On Thu, Mar 12, 2020 at 08:58:42AM +, Laxminarayan Bharadiya, Pankaj wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 10 March 2020 21:36
> > To: Laxminarayan Bharadiya, Pankaj
> >
> > Cc: jani.nik...@linu
On Thu, Mar 12, 2020 at 09:13:24AM +, Laxminarayan Bharadiya, Pankaj wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 10 March 2020 21:47
> > To: Laxminarayan Bharadiya, Pankaj
> >
> > Cc: jani.nik...@linu
+-
> drivers/gpu/drm/i915/display/intel_display.h | 2 +
> drivers/gpu/drm/i915/display/intel_sprite.c | 32 --
> drivers/gpu/drm/i915/i915_reg.h | 21
> include/drm/drm_crtc.h | 10 ++
> include/drm/drm_mode_c
On Thu, Mar 12, 2020 at 03:37:03PM +, Laxminarayan Bharadiya, Pankaj wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 12 March 2020 19:35
> > To: Laxminarayan Bharadiya, Pankaj
> >
> > Cc: jani.nik...@linu
On Fri, Mar 13, 2020 at 08:45:35AM +, Laxminarayan Bharadiya, Pankaj wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 12 March 2020 19:25
> > To: Laxminarayan Bharadiya, Pankaj
> >
> > Cc: jani.nik...@linu
On Mon, Mar 16, 2020 at 09:31:32AM +0100, Daniel Vetter wrote:
> On Tue, Mar 10, 2020 at 06:01:06PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 25, 2020 at 12:35:41PM +0530, Pankaj Bharadiya wrote:
> > > Introduce new scaling filter property to allow userspace to select
> >
On Fri, Mar 13, 2020 at 04:05:00PM -0400, Alex Deucher wrote:
> On Fri, Mar 13, 2020 at 12:21 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Make the topology id const since we don't want to change it.
> >
> > Signed-off-by: Vil
On Wed, Feb 12, 2020 at 10:08:49AM +0100, Daniel Vetter wrote:
> On Wed, Feb 12, 2020 at 10:07:55AM +0100, Daniel Vetter wrote:
> > On Tue, Feb 11, 2020 at 07:14:51PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 11, 2020 at 06:05:45PM +0100, Daniel Vetter wrote:
> > > &
On Wed, Mar 18, 2020 at 06:31:16PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-03-18 18:25:18)
> > From: Ville Syrjälä
> >
> > drm_mode_config_init() may not have been called when the driver/device
> > doesn't support modeset. That will cause drm_mo
On Wed, Mar 18, 2020 at 01:31:07PM -0700, Matt Roper wrote:
> On Wed, Mar 18, 2020 at 05:49:59PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently a driver must not provide a .dumb_create() hook in the
> > drm_driver structure if it wants to
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ä
> 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.syr
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ä
> 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.syr
new
> >> i915_calc_vbltimestamp_from_scanoutpos would then be fairly thin
> >> wrappers passing in the relevant get_scanout_position function.
> >
> > Of course. Will be in v2 of the series.
>
> Please give Ville (Cc'd) a moment before sending v2 in case
handover of that data seems to be not implemented in current
> > vgaswitcheroo. At the moment switching between AMD only or Intel+AMD
> > Prime setup is quite a pita...
> >
>
> I haven't followed the entire discussion on the i915 thread but for the
> amdgpu dc pat
static void set_dsc_configs_from_fairness_vars(struct
> dsc_mst_fairness_params *params,
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dr
returned to master/root
>
> Changes since v1:
> - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
> - update ioctl number
>
> Signed-off-by: Daniel Stone
> Signed-off-by: Juston Li
> Acked-by: Daniel Vetter
lgtm
Reviewed-by: Ville Syrjälä
> ---
> driv
nasi Navare wrote:
> > On Thu, Jan 09, 2020 at 03:08:52PM +0200, Ville Syrjälä wrote:
> > > On Tue, Jan 07, 2020 at 04:32:08PM -0800, Manasi Navare wrote:
> > > > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > > > the EDID's detailed d
> Hmm, I think this will try to init lspcon on ports that do not have
> lspcon. Also, why wouldn't we reset the params?
>
> I think this boils down to just adding the following lines:
>
> if (intel_bios_is_lspcon_present(dev_priv, intel_dig_port->base.port) &&
> !intel_dig_port->lspcon.active)
> lspcon_init(intel_dig_port);
>
>
> Ville?
This won't work right. Eg. intel_infoframe_init() assumes that lspcon
init happens during driver load. We should probably change that to just
trust the VBT and simply move the lspcon probe (if we even need one)
into dp_detect() instead of sprinkling it around in several places.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Jan 15, 2020 at 02:34:02PM +0200, Jani Nikula wrote:
> On Fri, 10 Jan 2020, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:26:19PM -0500, Harry Wentland wrote:
> >>
> >>
> >> On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
> >>
drm_crtc_index(crtc);
>
> vblank = &dev->vblank[pipe];
> - vblank_enabled = dev->vblank_disable_immediate &&
> READ_ONCE(vblank->enabled);
> + vblank_enabled = __vblank_disable_immediate(dev, pipe) &&
> + READ_ONCE(vblank->enabled);
>
> if (!vblank_enabled) {
> ret = drm_crtc_vblank_get(crtc);
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
splay mode. Only valid when @enabled
>* is set. This is used by helpers like
> - * drm_calc_vbltimestamp_from_scanoutpos(). We can't just access the
> - * hardware mode by e.g. looking at &drm_crtc_state.adjusted_mode,
> + * drm_crtc_vblank_helper_get_vblank_ti
_crtc(dcrtc);
> enum pipe pipe = crtc->pipe;
> int position;
> int vbl_start, vbl_end, hsync_start, htotal, vtotal;
> @@ -879,6 +881,14 @@ bool i915_get_crtc_scanoutpos(struct drm_device *dev,
> unsigned int index,
> return true;
> }
>
>
On Thu, Jan 16, 2020 at 09:44:55AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 15.01.20 um 15:49 schrieb Ville Syrjälä:
> > On Wed, Jan 15, 2020 at 01:16:34PM +0100, Thomas Zimmermann wrote:
> >> @@ -2020,3 +2042,193 @@ int drm_crtc_queue_sequence_ioctl(struct
> >
200, 0x0020 },
> + { 0x00010220, 0x34001c00, 0x1400, 0xfff8 },
> + { 0x07600032, 0x20001fa0, 0x008d0fe0, 0x8210 },
> + { 0x, 0x, 0x, 0x },
> + { 0x, 0x, 0x, 0x },
> + { 0x, 0x0000,
unt);
>
> +/*
> + * Helpers for struct drm_crtc_funcs
> + */
> +
> typedef bool (*drm_vblank_get_scanout_position_func)(struct drm_crtc *crtc,
>bool in_vblank_irq,
>int *vpos, int *hpos,
> @@ -259,5 +263,9 @@
> drm_crtc_vblank_helper_get_vblank_timestamp_internal(struct drm_crtc *crtc,
>bool in_vblank_irq,
>
> drm_vblank_get_scanout_position_func get_scanout_position,
>
> drm_vblank_get_scanout_position_legacy_func get_scanout_position_legacy);
> +bool drm_crtc_vblank_helper_get_vblank_timestamp(struct drm_crtc *crtc,
> + int *max_error,
> + ktime_t *vblank_time,
> + bool in_vblank_irq);
>
> #endif
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
-off-by: Thomas Zimmermann
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_vblank.c| 27 +++
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> include/drm/drm_vblank.h| 10 +-
> 3 files changed, 9 insertions(+), 30 deletions(-)
>
ures & feature;
> + return features && (dev->driver->driver_features & dev->driver_features
> &
> + features) == features;
Could maybe do with an extra variable?
u32 supported = driver->driver_features & dev->driver_features;
retur
DP_MST_EN |
> DP_UP_REQ_EN | DP_UPSTREAM_IS_SRC);
> + DP_MST_EN |
> + DP_UP_REQ_EN |
> + DP_UPSTREAM_IS_SRC);
Doesn't fit on one line?
Reviewed-by: Ville Syrjälä
mgr->vcpi_mask = 0;
> @@ -3550,6 +3554,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr *mgr, bool ms
>
> out_unlock:
> mutex_unlock(&mgr->lock);
> + mutex_unlock(&mgr->payload_lock);
> if (mstb)
>
On Wed, Jan 22, 2020 at 02:43:21PM -0500, Lyude Paul wrote:
> Mention that the size of these two structs is determined by
> max_payloads. Suggested by Ville Syrjälä.
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> ---
> include/drm/drm_dp_mst_helper.h | 6 --
ng destroyed along with the ports anyway.
>
> Changes since v1:
> * Use sizeof(mgr->payloads[0])/sizeof(mgr->proposed_vcpis[0]) instead -
> vsyrjala
>
> Cc: Sean Paul
> Cc: Wayne Lin
> Cc: Ville Syrjälä
> Signed-off-by: Lyude Paul
> ---
> drivers/
C_709 (1 << 1)
> +#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
> +#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
> +#define DRM_EDID_CLRMETRY_ADB_RGB (1 << 4)
> +#define DRM_EDID_CLRMETRY_BT2020_CYCC (1 << 5)
> +#define DRM_EDI
ed.
I do understand why new people make this mistake though; There
should probably be a more explicit indication that the first
line is the subject when editing the commit message.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jan 23, 2020 at 09:19:04AM -0800, Matt Roper wrote:
> On Thu, Jan 23, 2020 at 05:45:41PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To make it easier to figure out what caused a particular debug
> > message let's print out aux->name.
&g
On Mon, Jan 27, 2020 at 05:30:42PM -0500, Alex Deucher wrote:
> On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > After much head scratching I managed to convince myself that
> > for_each_displayid_db() has alread
On Mon, Jan 27, 2020 at 05:38:15PM -0500, Alex Deucher wrote:
> On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Let's try to make a lot more stuff const in the edid parser.
> >
> > The "downs
On Tue, Jan 28, 2020 at 04:17:58PM +0100, Daniel Vetter wrote:
> On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > CEA-861 says :
> > "d = offset for the byte following the reserved data block.
> > If no data
On Tue, Jan 28, 2020 at 05:18:34PM +0100, Daniel Vetter wrote:
> On Tue, Jan 28, 2020 at 5:15 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Jan 28, 2020 at 04:17:58PM +0100, Daniel Vetter wrote:
> > > On Fri, Jan 24, 2020 at 10:02:24PM +0200, Ville Syrjala wrote:
ere)?
> goto fail;
> }
>
> --
> 2.25.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
ll only work again when complete disabled
> and their power wells turned off causing a reset in their registers.
>
> Cc: Ville Syrjälä
> Cc: Matt Roper
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> 1 file changed, 1 insertion
On Thu, Jan 30, 2020 at 08:07:07PM +, Souza, Jose wrote:
> On Thu, 2020-01-30 at 19:25 +0200, Ville Syrjälä wrote:
> > On Thu, Jan 16, 2020 at 05:58:37PM -0800, José Roberto de Souza
> > wrote:
> > > TGL timeouts when disabling MST transcoder and fifo underruns over
>
utput_format = INTEL_OUTPUT_FORMAT_YCBCR420;
>
> /* YCBCR 420 output conversion needs a scaler */
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
..@lists.freedesktop.org; Andres Rodriguez
> > Subject: [Intel-gfx] [PATCH 6/8] drm/edid: Add a FIXME about DispID CEA
> > data block
> > revision
> >
> > From: Ville Syrjälä
> >
> > I don't understand what the DispID CEA data block revision means.
something else.
> {
> BUILD_BUG_ON(1 + ARRAY_SIZE(edid_cea_modes_1) - 1 != 127);
> BUILD_BUG_ON(193 + ARRAY_SIZE(edid_cea_modes_193) - 1 != 219);
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
d non-atomic drivers.
>
> While at it I also removed the mention of
> drm_atomic_helper_best_encoder() that was renamed in
> commit 297e30b5d9b6 ("drm/atomic-helper: Unexport
> drm_atomic_helper_best_encoder").
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
>
On Wed, Sep 11, 2019 at 08:01:55PM +, Souza, Jose wrote:
> On Wed, 2019-09-11 at 21:10 +0300, Ville Syrjälä wrote:
> > On Wed, Sep 11, 2019 at 10:56:02AM -0700, José Roberto de Souza
> > wrote:
> > > This 3 non-atomic drivers all have the same function getting the
>
_kms_helper module
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Signed-off-by: José Roberto de Souza
lgtm
Reviewed-by: Ville
DE_FLOAT 15
> +#define DRM_MODE_COLORIMETRY_RGB_CUSTOM_COLOR_PROFILE16
> +#define DRM_MODE_COLORIMETRY_BT601_YCC 17
> +#define DRM_MODE_COLORIMETRY_Y_ONLY_DICOM_P14_GRAYSCALE 18
> +#define DRM_MODE_COLORIMETRY_RAW_CUSTOM_COLOR_PROFILE19
>
>
901 - 1000 of 4031 matches
Mail list logo
