> pipe CSC bits so that the background color goes through the same color
> management transformations that a plane with black pixels would.
>
> v2: Rename register to SKL_BOTTOM_COLOR to more closely follow
> bspec naming. (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-
ent
> + * values being provided contain less than 16 bits of precision, they'll
> + * be shifted into the most significant bits.
> + */
> +static inline __u64
> +drm_argb(__u8 bpc, __u16 alpha, __u16 red, __u16 green, __u16 blue)
> +{
> + int msb_shift = 16 - bpc;
> +
dri-devel@lists.freedesktop.org
> Cc: wei.c...@intel.com
> Cc: harish.krupo@intel.com
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 9 +++
> drivers/gpu/drm/i915/intel_display.c | 46
> +++--
On Wed, Jan 30, 2019 at 06:11:16PM -0800, Matt Roper wrote:
> On Wed, Jan 30, 2019 at 11:01:25PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> > > Some display controllers can be programmed to present non-black colors
> > >
ors
>*
>* Holds the framebuffer and out-fence for a writeback connector. As
> @@ -995,6 +1034,12 @@ struct drm_connector {
> struct drm_property *content_protection_property;
>
> /**
> + * @colorspace_property: Connector property to set the suita
ev);
> + struct intel_digital_port *intel_dig_port =
> + hdmi_to_dig_port(intel_hdmi);
>
> intel_attach_force_audio_property(connector);
> intel_attach_broadcast_rgb_property(connector);
> intel_attach_aspect_ratio_property(connect
type == DRM_MODE_CONNECTOR_DisplayPort)
> {
> + prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
> + "Colorspace", dp_colorspaces,
> + ARRAY_SIZE(dp_colorspaces));
> +
&
Tina Zhang
> Cc: Uma Shankar
> Cc: Shashank Sharma
> Cc: Ville Syrjälä
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
This lgtm:
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_fourcc.c | 4
> include/uapi/drm/drm_fourcc.h
ted
> * Color Keying not supported
>
> v2:
> - Drop handling pixel normalize register
> - Don't use icl_is_hdr_plane too early
>
> Signed-off-by: Kevin Strasser
> Cc: Uma Shankar
> Cc: Shashank Sharma
> Cc: Ville Syrjälä
> Cc: David Airlie
>
On Fri, Feb 01, 2019 at 08:50:11PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 30, 2019 at 06:24:24PM +0530, Uma Shankar wrote:
> > Create a new connector property to program colorspace to sink
> > devices. Modern sink devices support more than 1 type of
> > colorspace like
On Mon, Feb 04, 2019 at 05:08:40PM +, Shankar, Uma wrote:
>
>
> >-Original Message-----
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Monday, February 4, 2019 8:55 PM
> >To: Shankar, Uma
> >Cc: intel-...@lists.freedesktop.or
On Fri, Feb 01, 2019 at 09:38:57PM +, Strasser, Kevin wrote:
> Ville Syrjälä wrote:
> > > @@ -1774,6 +1776,45 @@ static const u32 skl_planar_formats[] = {
> > >DRM_FORMAT_NV12,
> > > };
> > >
> > > +static const uint32_t icl_hdr_plane
ds the framebuffer and out-fence for a writeback connector. As
> @@ -995,6 +1038,12 @@ struct drm_connector {
> struct drm_property *content_protection_property;
>
> /**
> + * @colorspace_property: Connector property to set the suitable
> + * colorspace supported by the
orspace(struct hdmi_avi_infoframe *frame,
> + const struct drm_connector_state *conn_state);
> +
> void
> drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
> struct drm_connector *connector,
> --
> 1.9.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
On Tue, Feb 05, 2019 at 05:32:16PM +, Shankar, Uma wrote:
>
>
> >-Original Message-----
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, February 5, 2019 10:02 PM
> >To: Shankar, Uma
> >Cc: intel-...@lists.freedesktop.
On Tue, Feb 05, 2019 at 07:29:21PM -0800, Kevin Strasser wrote:
> Change the api in order to enable callers that can't supply a valid
> intel_plane pointer, as would be the case prior to calling
> drm_universal_plane_init.
>
> Cc: Uma Shankar
> Cc: Shashank Sharma
&g
ted
> * Color Keying not supported
>
> v2:
> - Drop handling pixel normalize register
> - Don't use icl_is_hdr_plane too early
>
> v3:
> - Use refactored icl_is_hdr_plane (Ville)
> - Use u32 instead of uint32_t (Ville)
>
> Cc: Uma Shankar
> Cc: Shasha
_kms_helper_hotplug_event()
That of course requires that no one is hanging on to the
kref(s). The lifetime of the references isn't really clear
to me, but I'll take your word that it works.
Reviewed-by: Ville Syrjälä
> + }
> }
> }
> --
> 2.20.1
>
ude Paul
> Cc: Imre Deak
> Cc: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c2399
On Tue, Feb 05, 2019 at 07:22:32PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Ville Syrjälä
> >Sent: Tuesday, February 5, 2019 11:43 PM
>
On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote:
> Regards
> Shashank
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > Shankar, Uma
> > Sent: Friday, February 8, 201
On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
> On 2/8/2019 6:22 PM, Ville Syrjälä wrote:
> > On Fri, Feb 08, 2019 at 12:36:25PM +, Sharma, Shashank wrote:
> >> Regards
> >> Shashank
> >>
> &
On Fri, Feb 08, 2019 at 07:36:24PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
> On 2/8/2019 7:00 PM, Ville Syrjälä wrote:
> > On Fri, Feb 08, 2019 at 06:36:39PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
&g
On Fri, Feb 08, 2019 at 03:03:34PM +, Shankar, Uma wrote:
>
>
> >-Original Message-----
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Friday, February 8, 2019 8:08 PM
> >To: Sharma, Shashank
> >Cc: Shankar, Uma ; intel-.
t;= 10 ?
> +
> + if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
> + return -EINVAL;
> +
> /*
>* We allow both degamma & gamma luts at the right size or
>* NULL.
> --
> 2.14.4
>
> _
> 2.20.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 Wed, Dec 19, 2018 at 04:24:40PM +0100, Daniel Vetter wrote:
> On Wed, Dec 19, 2018 at 04:33:01PM +0200, Ville Syrjälä wrote:
> > On Wed, Dec 19, 2018 at 01:42:41PM +, emersion wrote:
> > > I guess DRM_MODE_FLAG_PIC_AR_MASK has been overlooked.
> >
> > Nope.
; conclusion "no bools in structs at all" isn't. In this case, I think
> > > bools are the
> > > better option, and anything else makes the code worse.
> >
> > The solution was to use bit fields,
> > unsinged int is_paired:1;
n all SNB machines").
Can you file a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
and attach the full dmesg from the boot with drm.debug=0xe passed to the
kernel cmdline?
--
Ville Syrjälä
Intel
___
dri-
anently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Signed-off-by: Lyude Paul
mit adds code to intel_dsi_compute_config() to properly set
> pipe_bpp based on intel_dsi->pixel_format.
>
> Signed-off-by: Hans de Goede
lgtm
Reviewed-by: Ville Syrjälä
That said, I think we could make everything less confusing by doing
something like this:
compute_config() {
ay this was only made to work in C0 stepping. Not sure any
BYT-Ts were ever shipped with B2/3, nor am I sure if setting the bit
would have any effect there. IMO let's just set the bit and hope for
the best.
Reviewed-by: Ville Syrjälä
> +
> /* assert ip_tg_enable signal */
have pixel_rate in the crtc state
but atm that is computed in generic code. We might have to push that
to be encoder specific to do this correctly...
> +
> pipe_config->clock_set = true;
>
> return true;
> --
> 2.19.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
anently. Whoops.
>
> So, fix this by modifying ->compute_config() to pass down an actual
> error code instead of a bool so that the atomic check can be restarted
> on modeset deadlocks.
>
> Thanks to Ville Syrjälä for pointing this out!
>
> Changes since v1:
> * Ad
itect the library so that it would be
> shared with the kernel? Maybe the quirks database could be shared
> with the kernel as well? That way both kernel and userspace would
> more or less agree on the parsing details.
IIRC long ago I did manage to build drm_edid.c in userspace.
My ide
ff?
> };
>
> int drm_plane_create_color_properties(struct drm_plane *plane,
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Sy
On Fri, Jan 18, 2019 at 03:34:18PM +0100, Andrzej Hajda wrote:
> +CC: Hans
>
> On 17.01.2019 20:47, Ville Syrjälä wrote:
> > On Fri, Dec 14, 2018 at 01:10:16PM +0100, Christoph Manszewski wrote:
> >> Range setting makes sense for YCbCr and RGB buffers. Current
> >
rn -EINVAL;
> > + args->size = ALIGN(size, PAGE_SIZE);
> >
> > switch (args->bpp) {
> > case 16:
> > --
> > 2.9.3
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
> + [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
> + [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
> + [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
> + [DRM_MODE_COLORIMETRY_BT2
; + prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
> + "Colorspace", dp_colorspaces,
> + ARRAY_SIZE(dp_colorspaces));
> +
On Tue, Feb 19, 2019 at 03:09:00PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Tuesday, February 19, 2019 1:37
")
> > @@ -212,4 +213,5 @@ CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice
> > Lake 6x8 GT1.5)")
> > CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> > CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x
_mutex);
> - idr_remove(&aux_idr, aux_dev->index);
> - mutex_unlock(&aux_idr_mutex);
> + xa_erase(&aux_xa, aux_dev->index);
>
> atomic_dec(&aux_dev->usecount);
> wait_var_event(&aux_dev->usecount, !atomic_read(&aux_dev->usecount));
> --
> 2.20.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 Mon, Feb 25, 2019 at 10:42:46AM -0800, Matthew Wilcox wrote:
> On Mon, Feb 25, 2019 at 07:57:33PM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 21, 2019 at 10:41:23AM -0800, Matthew Wilcox wrote:
> > > @@ -49,8 +49,7 @@ struct drm_dp_aux_dev {
> > >
> >
On Wed, Feb 27, 2019 at 03:23:01PM -0500, Adam Jackson wrote:
> On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Some monitors apparently forget to mark any mode as preferred in the
> > EDID. In this particular case we hav
f (state && output->crc_enabled) {
> > - u64 frame = drm_crtc_accurate_vblank_count(crtc);
> > + u64 frame = vblank->count;
> >
> > /* update frame_start only if a queued vkms_crc_work_handle()
> > * has read the data
> > --
> > 2.17.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> 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 Fri, Mar 01, 2019 at 11:55:11AM -0300, Shayenne Moura wrote:
> Em qui, 28 de fev de 2019 às 11:03, Ville Syrjälä
> escreveu:
> >
> > On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote:
> > > On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote:
&
On Fri, Mar 01, 2019 at 03:35:35PM -0300, Shayenne Moura wrote:
> Em sex, 1 de mar de 2019 às 12:26, Ville Syrjälä
> escreveu:
> >
> > On Fri, Mar 01, 2019 at 11:55:11AM -0300, Shayenne Moura wrote:
> > > Em qui, 28 de fev de 2019 às 11:03, Ville Syrjälä
> > &g
t;
> + if (ignore_edid_audio)
> + goto end;
> +
> edid_ext = drm_find_cea_extension(edid);
> if (!edid_ext)
> goto end;
> --
> git-series 0.9.1
> __________
nstead of the analog jack". Do we have some way for DRM
> > > to communicate to ALSA that this is not the right place to try to play
> > > audio by default?
> >
> > Apparently not. We have users using debug knobs in our drive
On Tue, Mar 05, 2019 at 05:24:13PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 05, 2019 at 10:12:40AM +0100, Maxime Ripard wrote:
> > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote:
> > > On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote:
> > > >
On Tue, Mar 05, 2019 at 02:21:04PM -0500, Alex Deucher wrote:
> On Tue, Mar 5, 2019 at 2:15 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Mar 05, 2019 at 05:24:13PM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 05, 2019 at 10:12:40AM +0100, Maxime Ripard wrote:
> >
On Sun, Mar 10, 2019 at 05:35:05PM -0300, Rodrigo Siqueira wrote:
> On 03/01, Ville Syrjälä wrote:
> > On Fri, Mar 01, 2019 at 03:35:35PM -0300, Shayenne Moura wrote:
> > > Em sex, 1 de mar de 2019 às 12:26, Ville Syrjälä
> > > escreveu:
> > > >
> >
> 2.19.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
m convention is to put this above the --- so that it gets included in
the commit msg.
With that
Reviewed-by: Ville Syrjälä
>
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.
ebuffer has some clear limitations:
* something may overwrite the oops message before the user
can even read it
* there may be other planes obscuring part or all of the
primary plane
Also scribbling over the user's framebuffer seems rather rude
to me, so I'm thinking this approach should be limited to kernel
panics only.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>
>
> Den 12.03.2019 17.17, skrev Ville Syrjälä:
> > On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> >> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> >>> This adds support for
On Tue, Mar 12, 2019 at 06:37:57PM +0100, Noralf Trønnes wrote:
>
>
> Den 12.03.2019 18.25, skrev Ville Syrjälä:
> > On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 12.03.2019 17.17, skrev Ville Syrjälä:
> >>
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
> On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
> >
> >
> > Den 12.03.2019 17.17, skrev Ville Syrjälä:
> >> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> >>> On
On Tue, Mar 12, 2019 at 03:59:15PM +, Kieran Bingham wrote:
> Hi Ville,
>
> On 12/03/2019 15:14, Ville Syrjälä wrote:
> > On Tue, Mar 12, 2019 at 12:33:07AM +, Kieran Bingham wrote:
> >> Trivial fixes identified while working on the DRM code.
> >>
modetest: add FP16 format support
> >
> > tests/modetest/buffers.c | 13 ++
> > tests/modetest/modetest.c | 109 --
> > tests/util/format.c | 7 +
> > tests/util/pattern.c | 432 +-
> > tests/util/pattern.h
ng/removing
pcm devices when the correcponding drm connector is added/removed.
If we don't want to/can't add such pcm devices then we'd need to
dynamically change the symlinks/whatever whenever an MST stream
is started/stopped. And probably we should do the same for SST/HDMI
as well, if for no other reason than to make sure userspace is
prepared for it even if they didn't test with MST.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
mipi_config->target_burst_mode_freq = bitrate;
Maybe should squash these patches together to make the stable
backport less painful?
Anyways, seems OK to me.
Reviewed-by: Ville Syrjälä
> +
> if (mipi_config->target_burst_mode_freq < bitrate) {
>
915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
> index fce8b58f7f93..3329ccf3b346 100644
> --- a/drivers/gpu/drm/i915/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/vlv_dsi.c
> @@ -1782,6 +1782,8 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
> goto err;
>
On Fri, May 24, 2019 at 06:30:18PM +0200, Hans de Goede wrote:
> This is a preparation patch for moving the calling of *_dphy_param_init()
> out of intel_dsi_vbt_init.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/in
gt; + intel_dsi->pclk = current_mode->clock;
> + }
I wonder if we should be checking whether the mode is otherwise
identical to whatever we got from VBT? Though I suppose that shouldn't
really happen.
The whole dsi clock handling is a proper
,
> otherwise they are completely unchanged.
>
> Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 108 ++
> drivers/gpu/drm/i915/intel_dsi.h | 1 +
> drivers/gpu/drm/i915/intel_dsi_vbt.c | 282 +--
c: Tomeu Vizoso
> Cc: Emil Velikov
> Cc: Benjamin Gaignard
> Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs
On Wed, May 29, 2019 at 06:50:40PM +0200, Mario Kleiner wrote:
> On Wed, May 29, 2019 at 7:02 AM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > From VESA EDID implementation guide v1.0:
> > "For EDID version 1 revision 2 or earlier data struct
I'm still not sure whether this is fixed on all hardware or not.
>
> Ville, on this old Intel hw, is the single connector that gets the
> audio configurable?
The force-audio property can be used for that. That is, you can force
audio off for all the connector where you don't want audio and then
it should get automagically routed to the remaining connector.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Jun 07, 2019 at 08:40:15PM +0200, Daniel Vetter wrote:
> On Fri, Jun 07, 2019 at 07:26:10PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > i915 will now refuse to enable a C8 plane unless the gamma_lut
> > is already enabled (to avoid scanni
On Fri, Jun 07, 2019 at 08:43:56PM +0200, Daniel Vetter wrote:
> On Fri, Jun 07, 2019 at 07:26:11PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Respect the user's choice of depth/bpp for the fbdev framebuffer
> > and throw out the fb we inher
On Tue, Jun 11, 2019 at 07:55:45PM +0200, Daniel Vetter wrote:
> On Tue, Jun 11, 2019 at 7:50 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Jun 07, 2019 at 08:40:15PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 07, 2019 at 07:26:10PM +0300, Ville Syrjala wrote:
On Tue, May 28, 2019 at 05:06:49PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> CH7511 eDP->LVDS bridge doesn't seem to set SINK_COUNT properly
> causing i915 to detect it as disconnected. Add a quirk to ignore
> SINK_COUNT on these devices.
>
> Cc: Davi
} else {
> /* some kind of default for drivers w/o accurate vbl
> timestamping */
> diff = in_vblank_irq ? 1 : 0;
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> h
gt; struct reservation_object __builtin_resv;
> };
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5098228f1302..4f8b368ac4e2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10066,7 +10066,7 @@ static u32 intel_cursor_base(const struct
> intel_plane_state *plane_state)
> u32 base;
>
> if (INTEL_INFO(dev_priv)->display.cursor_needs_physical)
> - base = obj->phys_handle->busaddr;
> + base = obj->phys_handle;
> else
> base = intel_plane_ggtt_offset(plane_state);
>
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
- return -EINVAL;
> > + return -EOPNOTSUPP;
> >
> > if (vblwait->request.type & _DRM_VBLANK_SIGNAL)
> > - return -EINVAL;
> > + return -EOPNOTSUPP;
> >
> > if (vblwait->request.type &am
at one place. Addressed Alexandru's review
> > > > comments.
> > > >
> > > > v6: Rebase. Added support for ICL Color features. Enhanced Lut
> > > > precision to accept input values in u32.32 format. This is needed for
> > > >
On Wed, Jun 19, 2019 at 12:33:33PM -0300, Ezequiel Garcia wrote:
> On Wed, 2019-06-19 at 18:03 +0300, Ville Syrjälä wrote:
> > On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> > > On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > >
h, that achieves the goal?
>
> Input and ideas from the Intel team and DRM community are very much
> appreciated.
>
> Thanks
> Emil
> _______
> 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 Wed, Jun 19, 2019 at 06:49:11PM +0100, Emil Velikov wrote:
> On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä
> wrote:
> >
> > On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> > > Hi all,
> > >
> > > Recently I have been look
On Thu, Jun 20, 2019 at 11:59:37AM -0400, Ilia Mirkin wrote:
> On Thu, Jun 20, 2019 at 11:46 AM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Currently the logs show nothing about the mode's aspect ratio.
> > Include that information in the
On Thu, Jun 20, 2019 at 10:25:42PM +0200, Sam Ravnborg wrote:
> Hi Ville.
>
> On Thu, Jun 20, 2019 at 09:50:48PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Decode the mode flags when printing the modeline so that I
> > no longer have to decode
s_property(struct
> drm_connector *connector,
> void drm_connector_set_vrr_capable_property(
> struct drm_connector *connector, bool capable);
> int drm_connector_init_panel_orientation_property(
> + struct drm_connector *connector);
> +int drm_connector_init_panel_orientation_property_quirk(
> struct drm_connector *connector, int width, int height);
> int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
> int min, int max);
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
On Fri, Jun 21, 2019 at 07:28:30PM -0400, Alex Deucher wrote:
> On Thu, Jun 20, 2019 at 10:26 AM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Ilia pointed out some oddball crap in the i915 aspect ratio handling.
> > While looking at that I no
vblank->framedur_ns);
> + }
> +
> + store_vblank(dev, pipe, diff, now, vblank->count);
> +
> goto out;
> + }
>
> /*
>* Update the count and timestamp to maintain the
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
; Increasing the limit to 32 does however increases the size of the static
> u32 array keeping track of the encoder IDs.
>
> Cc: José Roberto de Souza
> Cc: Ville Syrjälä
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Dhinakaran Pandiyan
> ---
> include/drm/drm_con
_count(dev, pipe, false);
> - __disable_vblank(dev, pipe);
> - vblank->enabled = false;
>
> -out:
> spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags);
> }
>
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
DRM_MODE_SUBCONNECTOR_VGA= 1, /*DP */
> + DRM_MODE_SUBCONNECTOR_DVI= 2, /*DP */
> + DRM_MODE_SUBCONNECTOR_DVID = 3, /* DVI-I */
> + DRM_MODE_SUBCONNECTOR_DVIA = 4, /* DVI-I */
> + DRM_MODE_SUBCONNECTOR_C
t;dev->mode_config.mutex);
> + return ret;
> +}
> +
> static DEVICE_ATTR_RW(status);
> static DEVICE_ATTR_RO(enabled);
> static DEVICE_ATTR_RO(dpms);
> static DEVICE_ATTR_RO(modes);
> +static DEVICE_ATTR_RO(mstpath);
>
> static struc
emp & TRANS_DDI_MODE_SELECT_MASK) {
> case TRANS_DDI_MODE_SELECT_HDMI:
> pipe_config->has_hdmi_sink = true;
> - intel_dig_port = enc_to_dig_port(&encoder->base);
>
> pipe_config->infoframes.enable |=
>
ndex = DRRS_HIGH_RR;
> @@ -6636,9 +6634,6 @@ static void intel_dp_set_drrs_state(struct
> drm_i915_private *dev_priv,
> return;
> }
>
> - dig_port = dp_to_dig_port(intel_dp);
> - encoder = &dig_port->base;
> -
> if (!intel_crtc) {
> DRM_
return NULL;
> +
> /* allocate the drm_display_mode structure. If failure, we will
>* return directly
>*/
> @@ -392,6 +395,9 @@ drm_gtf_mode_complex(struct drm_device *dev, int
> hdisplay, int vdisplay,
> int hsync, hfront_porch, vodd_front_
p_mst_connector_early_unregister,
> .destroy = intel_connector_destroy,
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> .atomic_duplicate_state = intel_digital_connector_duplicate_state,
> --
> 2.22.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
gt; v2: remove unnecessary locking of mode_config.mutex
>
> Signed-off-by: Leo Li
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_sysfs.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.
e->planes[i].old_state = plane->state;
>
> + for_each_new_private_obj_in_state(state, privobj, new_priv_state, i)
> + state->private_objs[i].old_state = privobj->state;
> +
> for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
>
On Fri, Mar 15, 2019 at 08:51:57AM -0300, Rodrigo Siqueira wrote:
> On 03/11, Ville Syrjälä wrote:
> > On Sun, Mar 10, 2019 at 05:35:05PM -0300, Rodrigo Siqueira wrote:
> > > On 03/01, Ville Syrjälä wrote:
> > > > On Fri, Mar 01, 2019 at 03:35:35PM -0300, Shayenne Mo
xels */
> +#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0]
> Cr0:Y1:Cb0:Y0 16:16:16:16 little endian per 2 Y pixels */
>
> /*
> * packed Y4xx indicate for each component, xx valid data occupy msb
> * 16-xx padding occupy lsb except Y410
> */
> -#
On Tue, Mar 19, 2019 at 05:06:36PM +0100, Maarten Lankhorst wrote:
> Op 19-03-2019 om 14:02 schreef Ville Syrjälä:
> > On Tue, Mar 19, 2019 at 01:17:02PM +0100, Maarten Lankhorst wrote:
> >> There has unfortunately been a conflict with the following 3 commits
gt; > .depth = 0,
> > .num_planes = 1,
> > .cpp = { 2, 0, 0 },
> > @@ -632,6 +661,44 @@ const struct image_format_info
> > *image_format_drm_lookup(u32 drm)
> > EXPORT_SYMBOL(image_format_drm_lookup
501 - 600 of 4031 matches
Mail list logo
