similar to: Improvement suggestion to "How do I disable IPv6"

From: Ville Syrjälä <ville.syrjala at linux.intel.com> We now have per-device driver_features, so let's use that to disable atomic only for pre-nv50. Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: nouveau at lists.freedesktop.org Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>

On Thu, Sep 13, 2018 at 11:02 PM, Lyude Paul <lyude at redhat.com> wrote: > Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends on > the driver supporting atomic, maybe it would be good to make it so that we set > DRIVER_ATOMIC in the driver_stub structure, then disable it per-device depending > on the nouveau_atomic setting + hw support. That way we can

On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala > <ville.syrjala at linux.intel.com> wrote: >> From: Ville Syrjälä <ville.syrjala at linux.intel.com> >> >> Replace the ad-hoc iturbt_709 property with the new standard >> COLOR_ENCODING property. Compiles, but not tested.

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> I really just wanted to fix i915 to re-enable its planes afer load detection (a two line patch). This is what I actually ended up with after I ran into a framebuffer refcount leak with said two line patch. I've tested this on a few i915 boxes and so far it's looking good. Everything else is just compile tested. Entire series

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> I really just wanted to fix i915 to re-enable its planes afer load detection (a two line patch). This is what I actually ended up with after I ran into a framebuffer refcount leak with said two line patch. I've tested this on a few i915 boxes and so far it's looking good. Everything else is just compile tested. Entire series

On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote: > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä > <ville.syrjala at linux.intel.com> wrote: > > > > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote: > > > This should probably be fixed to account for the scenario where an > > > HDMI connector is plugged directly into the DP++ port. I

From: Ville Syrjälä <ville.syrjala at linux.intel.com> Changes from the previous version mainly involve Danoie's suggestion of hiding the drm_encoder_find() in the iterator macro. I also polished the msm and tilcdc cases a bit more with another small helper. Cc: Alex Deucher <alexander.deucher at amd.com> Cc: amd-gfx at lists.freedesktop.org Cc: Ben Skeggs <bskeggs at

While I thought I had this correct (since it actually did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max symbol rate supported by the encoder, so limiting clock to ds_clock using max() doesn't make sense. Additionally, we want to check against 6bpc for the time being since that's the

On 03.12.2018 22:38, Ville Syrjälä wrote: > On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: >> On 21.11.2018 19:19, Laurent Pinchart wrote: >>> Hi Ville, >>> >>> Thank you for the patch. >>> >>> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: >>>> From: Ville Syrjälä <ville.syrjala at

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? > <ville.syrjala at linux.intel.com> 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 > > > are not simple but contains a display

On 21.11.2018 19:19, Laurent Pinchart wrote: > Hi Ville, > > Thank you for the patch. > > On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote: >> From: Ville Syrjälä <ville.syrjala at linux.intel.com> >> >> Make life easier for drivers by simply passing the connector >> to drm_hdmi_avi_infoframe_from_display_mode() and >>

On 05.12.2018 07:32, Laurent Pinchart wrote: > Hi Ville, > > On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote: >> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote: >>> On 03.12.2018 22:38, Ville Syrjälä wrote: >>>> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: >>>>> On 21.11.2018 19:19, Laurent Pinchart

On Mon, 2020-09-28 at 16:01 +0300, Ville Syrj?l? wrote: > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote: > > While I thought I had this correct (since it actually did reject modes > > like I expected during testing), Ville Syrjala from Intel pointed out > > that the logic here isn't correct. max_clock refers to the max symbol > > rate supported by the

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> We want to get rid of plane->crtc on atomic drivers. Stop setting it. v2: s/fb/crtc/ in the commit message (Gerd) Cc: David Airlie <airlied at linux.ie> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org Signed-off-by: Ville Syrj?l? <ville.syrjala at linux.intel.com>

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> Here are again the last (?) bits of eliminating the plane->fb/crtc usage for atomic drivers. I've pushed everything else (thanks to everyone who reviewed them). Deepak said he'd tested the vmwgfx stuff, so I think it should be safe to land. Just missing a bit of review... Cc: Alex Deucher <alexander.deucher at

From: Ville Syrjälä <ville.syrjala at linux.intel.com> This series first unifies all users of drm_atomic_helper_check_plane_state() to populate the clip rectangle with drm_mode_get_hv_timing(), and once everything is unified the clip rectangle handling is sucked into drm_atomic_helper_check_plane_state() away from driver code. Entire series available here:

On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote: > On Fri, 11 May 2018 19:54:02 +0300 > Ville Syrjälä <ville.syrjala at linux.intel.com> wrote: > > > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote: > > > On Fri, 11 May 2018 18:34:50 +0300 > > > Ville Syrjälä <ville.syrjala at linux.intel.com> wrote: > > >

It looks like that when we moved over to using drm_connector_for_each_possible_encoder() in nouveau, that one rather important part of this function got dropped by accident: /* Right v here */ for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) { int id = connector->encoder_ids[i]; if (id == 0) break; Since it's rather difficult to notice: the

Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh Message-ID: <20200226115708.GH13686 at intel.com> References: <20200219203544.31013-1-ville.syrjala at linux.intel.com> <CGME20200219203620eucas1p24b4990a91e758dbcf3e9b943669b0c8f at eucas1p2.samsung.com> <20200219203544.31013-5-ville.syrjala at linux.intel.com> <0f278771-79ce-fe23-e72c-3935dbe82d24 at

On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote: > On 03.12.2018 22:38, Ville Syrjälä wrote: > > On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote: > >> On 21.11.2018 19:19, Laurent Pinchart wrote: > >>> Hi Ville, > >>> > >>> Thank you for the patch. > >>> > >>> On Tuesday, 20 November 2018