search for: syrjala

...ed number of points (36) but that they are repeated (4 times)? I did GLMs to test for correlations between the two (hence forgetting about the spatial aspect of it) and was previously pointed to the SADIE software. Would there be anything explicitly spatial and available in R please? Then, Syrjala's test[1] seems appropriate and tests for differences in distribution. It computes a Cram?r-von Mises-type statistic and tests its significance with a permutation test. I implemented the test in R and posted the code on these mailing lists[2]. Some people checked it and confirmed that the...

...y (4 times) the abundance of organisms and measured environmental parameters. I now want to compare the spatial distribution of various species (and test wether they differ or not), or to compare the distribution of a particular organism with the distribution of some environmental variable. Syrjala's test[2] seems to be appropriate for such comparisons. The hamming distance is also used (but it is not associated with a test). However, as far as I understand it, Syrjala's test only compares the distribution gathered during one sampling event, while I have four successive repeat...

Hi, I went ahead and implemented something. However: - I cannot garantie it gives correct results since, unfortunately, the data used in Syrjala 1996 is not published along with the paper. To avoid mistakes, I started by coding things in a fast and simple way and then tried to optimize the code. At least all versions given the same results. - As expected, the test is still quite slow since it relies on permutations to compute the p....

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. >> >> Cc: Daniel Vetter &...

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&gt...

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:...

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...

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...

...es_atomic_modsetting(), and not DRIVER_ATOMIC. Former is about the internals (i915 is internally atomic everywhere), latter about the uapi (some old platforms aren't properly validated for full atomic features, hence why it's disabled). -Daniel > On Thu, 2018-09-13 at 19:31 +0300, Ville Syrjala wrote: >> 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...

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 minimum possible bpc...

...v Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ________________________________________ From: Intel-gfx [intel-gfx-bounces at lists.freedesktop.org] on behalf of Lisovskiy, Stanislav [stanislav.lisovskiy at intel.com] Sent: Monday, April 23, 2018 4:59 PM To: Ville Syrjala; dri-devel at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org; intel-gfx at lists.freedesktop.org; Ben Skeggs Subject: Re: [Intel-gfx] [PATCH] drm: Don't pass the index to drm_property_add_enum() Acked-by: Stanislav Lisovskiy <stanislav.lisovskiy at intel.com> Best Regards,...

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 samsung.com> <20200225112114.GA13686 at intel.com> <3ca785f2...

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 don't think > > > the...

On Tue, Feb 27, 2018 at 12:54:47AM -0500, Ilia Mirkin wrote: > 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. > >&gt...

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 >> drm_hdmi_avi_infoframe_quant_range(). That way drivers don't >> n...

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...

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. > > Cc: Daniel Vetter <daniel at ffwll.ch> &gt...

From: Ville Syrjälä <ville.syrjala at linux.intel.com> drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. Cc: Patrik Jakobsson <patrik.r.jakobsson at gmail.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Ville...

...8 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 linux.intel.com> >>>> >>>> Make life easier for drivers by simply passing the connector >>>> to drm_hdmi_avi_infoframe_from_display_mode() and >>>> drm_hdmi_avi_infoframe_quant_range(...

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 controller and memory. > > > That mea...