Hi Tvrtko,
On Fri, 30 Oct 2015 10:22:08 +
Tvrtko Ursulin wrote:
>
> On 30/10/15 01:44, Vivek Kasireddy wrote:
> > The main goal of this subtest is to trigger the following warning in
> > the function i915_gem_object_get_fence():
> > if (WARN_ON(!obj->map_and_fenceable))
> >
> > To trigg
On Fri, Oct 30, 2015 at 03:36:28PM -0700, Rafael Antognolli wrote:
> This module is heavily based on i2c-dev. Once loaded, it provides one
> dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
>
> It's possible to know which connector owns this aux channel by looking
> at the re
One branch of the if clause uses pr_info, the other pr_err; change
the 'false' branch to also use pr_info. This minor oversight has gone
unfixed since the initial vga_switcheroo implementation in 6a9ee8af.
Signed-off-by: Ioan-Adrian Ratiu
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
1 file change
This series implement support to a drm_dp_aux chardev that allows reading and
writing an arbitrary amount of bytes to arbitrary dpcd register addresses using
regular read, write and lseek operations.
Rafael Antognolli (2):
drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.
dr
So far, the i915 driver and some other drivers set it to the drm_device,
which doesn't allow one to know which DP a given aux channel is related
to. Changing this to be the drm_connector provides proper nesting, still
allowing one to get the drm_device from it. Some drivers already set it
to the dr
This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector
From: Ville Syrjälä
Currently there's no trace in dmesg when the gen2/3 dotclock checks
reject the modeset. Add some to avoid further head scratching.
While at it refactor the code a bit to look nicer.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 26
On Fri, Oct 30, 2015 at 01:59:22PM -0700, Rafael Antognolli wrote:
> On Fri, Oct 30, 2015 at 12:04:17PM +0200, Ville Syrjälä wrote:
> > On Thu, Oct 29, 2015 at 04:23:45PM -0700, Rafael Antognolli wrote:
> > > This module is heavily based on i2c-dev. Once loaded, it provides one
> > > dev node per D
From: Ville Syrjälä
This reverts commit b26a6b35581c84124bd78b68cc02d171fbd572c9.
commit b26a6b35581c ("drm/i915: Make prepare_plane_fb fully interruptible.")
breaks GPU reset on gen3/4 machines. Go back to to non-interruptible.
Cc: Maarten Lankhorst
Cc: Ander Conselvan de Oliveira
Signed-off
On Fri, Oct 30, 2015 at 12:04:17PM +0200, Ville Syrjälä wrote:
> On Thu, Oct 29, 2015 at 04:23:45PM -0700, Rafael Antognolli wrote:
> > This module is heavily based on i2c-dev. Once loaded, it provides one
> > dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
> >
> > It's poss
WW44 Regression report.
This week's regressions
+---+---+++
| BugId | Summary | Created on | Bisect |
+---+---+++
| 92655 |
On Tue, Jun 30, 2015 at 10:06:27AM +0100, Lukas Wunner wrote:
> From: Tvrtko Ursulin
>
> We had two failure modes here:
>
> 1.
> Deadlock in intelfb_alloc failure path where it calls
> drm_framebuffer_remove, which grabs the struct mutex and intelfb_create
> (caller of intelfb_alloc) was already
On Sat, Oct 24, 2015 at 12:27:57AM +0200, Lukas Wunner wrote:
> intelfb_create() is called once on driver initialization. It either
> uses the fb inherited from BIOS or allocates a new one by calling
> intelfb_alloc(). Afterwards, it calls two functions which can fail:
>
> - drm_fb_helper_alloc_fb
On Thu, Oct 22, 2015 at 01:37:18PM +0200, Lukas Wunner wrote:
> In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails,
> the bo is unrefed twice: By drm_framebuffer_remove() and once more by
> drm_gem_object_unreference(). Fix it.
>
> Reported-by: Ville Syrjälä
> Signed-off-by: Lu
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: fba7fdd3589b453770f28caa39064b6c0141e81a
commit: b8a8f412df08b100bbb6845c50f73656d677d08a [4/8] Merge remote-tracking
branch 'drm-upstream/drm-next' into drm-intel-nightly
config: x86_64-randconfig-x007-10252017 (attached as
On Fri, Oct 30, 2015 at 05:06:27PM +0100, Daniel Vetter wrote:
> On Tue, Oct 27, 2015 at 04:31:56PM +0200, Ville Syrjälä wrote:
> > On Tue, Oct 27, 2015 at 03:43:03PM +0200, Jani Nikula wrote:
> > > On Tue, 27 Oct 2015, ville.syrj...@linux.intel.com wrote:
> > > > From: Ville Syrjälä
> > > >
> > >
From: Ville Syrjälä
Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not
always get an interrupt on a FIFO underrun. But we can always do an
explicit check (like we do on GMCH platforms that have no underrun
interrupt).
v2: Drop stale kerneldoc for i9xx_check_fifo_underruns() (Dan
From: Ville Syrjälä
Doing the IBX transcoder B workaround causes underruns on
pipe/transcoder A. Just hide them by disabling underrun reporting for
pipe A around the workaround.
It might be possible to avoid the underruns by moving the workaround
to be applied only when enabling pipe A. But I wa
From: Ville Syrjälä
Some hardware (IVB/HSW and CPT/PPT) have a shared error interrupt for
all the relevant underrun bits, so in order to keep the error interrupt
enabled, we need to have underrun reporting enabled on all PCH
transocders. Currently we leave the underrun reporting disabled when
the
From: Ville Syrjälä
We get spurious PCH FIFO underruns if we enable the reporting too soon
after enabling the crtc. Move it to be the last step, after the encoder
enable. Additionally we need an extra vblank wait, otherwise we still
get the underruns. Presumably the pipe/fdi isn't yet fully up an
On Fri, Oct 30, 2015 at 05:18:15PM +0100, Daniel Vetter wrote:
> On Fri, Oct 23, 2015 at 10:17:44PM +0100, Dave Gordon wrote:
> > On 08/10/15 21:50, Wayne Boyer wrote:
> > >From: Chris Wilson
> > >
> > >A long time ago (before 3.14) we relied on a permanent pinning of the
> > >ifbdev to lock the f
On Fri, Oct 30, 2015 at 05:14:21PM +0100, Daniel Vetter wrote:
> On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote:
> > When accessing through the GTT from one CPU whilst concurrently updating
> > the GGTT PTEs in another thread, the hardware likes to return random
> > data. As we have s
From: Ville Syrjälä
My Lenovo STM STDP3100 miniDP->VGA dongle doesn't seem to like it when
we try to start link training with non-zero vswing/preemphasis. So when
the initial link training DPCD write fails, retry it with zero values.
Fixes a bunch of errors like so:
[drm:intel_dp_start_link_trai
Chris Wilson writes:
> On Fri, Oct 30, 2015 at 05:18:18PM +0200, Mika Kuoppala wrote:
>> Chris Wilson writes:
>>
>> > On Fri, Oct 30, 2015 at 04:43:49PM +0200, Mika Kuoppala wrote:
>> >> Gen9 has had demonstrated cases where forcing a not ready gpu
>> >> into reset has caused system hang [1].
>
On Fri, Oct 30, 2015 at 05:00:42PM +0100, Daniel Vetter wrote:
> On Thu, Oct 29, 2015 at 09:26:02PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Use intel_dp->DP in the eDP PLL setup, instead of doing RMWs.
> >
> > To do this we need to move DP_AUDIO_OUTPUT_ENABLE
On Fri, Oct 23, 2015 at 10:17:44PM +0100, Dave Gordon wrote:
> On 08/10/15 21:50, Wayne Boyer wrote:
> >From: Chris Wilson
> >
> >A long time ago (before 3.14) we relied on a permanent pinning of the
> >ifbdev to lock the fb in place inside the GGTT. However, the
> >introduction of stealing the BI
On Fri, Oct 23, 2015 at 06:43:32PM +0100, Chris Wilson wrote:
> When accessing through the GTT from one CPU whilst concurrently updating
> the GGTT PTEs in another thread, the hardware likes to return random
> data. As we have strong serialisation prevent us from modifying the PTE
> of an active GT
On Mon, Oct 26, 2015 at 10:48:58AM +, tim.g...@intel.com wrote:
> From: Tim Gore
>
> Since A1 chips use the same GPU as A0, they need all the
> same wa's in the i915 driver. Update some conditionals
> to do this.
Neither summary nor commit message mentions that this is for bxt. Please
fix.
-
On 10/30/2015 05:50 AM, Jani Nikula wrote:
Reported-by: Keith Webb
Suggested-by: Keith Webb
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106671
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm
On Fri, Oct 30, 2015 at 05:00:49PM +0530, Sagar Arun Kamble wrote:
> RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
> configuration registers. If those are not setup Driver should not enable RC6.
> For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
> to kn
On Fri, Oct 30, 2015 at 05:00:49PM +0530, Sagar Arun Kamble wrote:
> RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
> configuration registers. If those are not setup Driver should not enable RC6.
> For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
> to kn
On Tue, Oct 27, 2015 at 04:31:56PM +0200, Ville Syrjälä wrote:
> On Tue, Oct 27, 2015 at 03:43:03PM +0200, Jani Nikula wrote:
> > On Tue, 27 Oct 2015, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > The difference betwen the BXT and BDW cdclk code boils down to two
> > >
On Thu, Oct 29, 2015 at 09:26:03PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> ironlake_set_pll_cpu_edp() only gets called just before
> ironlake_edp_pll_on(), so just pull the code into ironlake_edp_pll_on().
>
> Also toss in a debug print into ironlake_edp_pll_off() t
On Thu, Oct 29, 2015 at 09:26:02PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Use intel_dp->DP in the eDP PLL setup, instead of doing RMWs.
>
> To do this we need to move DP_AUDIO_OUTPUT_ENABLE setup to happen later,
> so that we don't enable audio accidentally while c
Tail needs to be in outer scope as it is used after loop
continuation destroying its scope.
Reported-by: Thomas Wood
Cc: Thomas Wood
Signed-off-by: Mika Kuoppala
---
tests/drv_hangman.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/drv_hangman.c b/tests/drv_hangman.
We check these to determine firmware loading status. Include
them to help to debug causes of firmware loading fails.
v2: Move all CSR specific registers to i915_reg.h (Ville)
v3: Rebase
v4: Rebase (RPM ref)
Signed-off-by: Mika Kuoppala
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_debug
From: Damien Lespiau
The CSR firmware expose two counters, handy to check if we are indeed
entering DC5/DC6.
v2: Rebase
v3: Take RPM ref before reading (Imre)
Signed-off-by: Damien Lespiau
Reviewed-by: Rodrigo Vivi (v1)
Signed-off-by: Mika Kuoppala
Reviewed-by: Imre Deak
---
drivers/gpu/dr
On Thu, Oct 29, 2015 at 09:26:01PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rewrite the eDP PLL state asserts to conform to our usual state assert
> style.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_dp.c | 54
There is known issue on GT interrupt delivery with DC6 and
firmwares <1.21. There is a suspicion that this causes
spurious gpu hangs on driver init and with some workloads,
as upgrading the firmware to 1.21 makes these problems
disappear.
As of now the current version included in distribution
firm
On Thu, Oct 29, 2015 at 09:25:59PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The DP link frequency is 162MHz, not 160MHz. Rename the ILK eDP PLL
> defines to match.
>
> Signed-off-by: Ville Syrjälä
ocd ftw. Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/
On Thu, Oct 29, 2015 at 09:25:55PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not
> always get an interrupt on a FIFO underrun. But we can always do an
> explicit check (like we do on GMCH platforms that ha
On Thu, Oct 29, 2015 at 11:21:28PM +0200, Ville Syrjälä wrote:
> On Thu, Oct 29, 2015 at 05:57:57PM -0200, Paulo Zanoni wrote:
> > 2015-10-29 17:25 GMT-02:00 :
> > > From: Ville Syrjälä
> > >
> > > We get spurious PCH FIFO underruns if we enable the reporting too soon
> > > after enabling the crt
On Fri, Oct 30, 2015 at 02:08:51PM +0200, Ville Syrjälä wrote:
> On Fri, Oct 30, 2015 at 12:06:09PM +0200, Jani Nikula wrote:
> > On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > We get spurious PCH FIFO underruns if we enable the reporting too soon
>
On Fri, Oct 30, 2015 at 05:18:18PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Fri, Oct 30, 2015 at 04:43:49PM +0200, Mika Kuoppala wrote:
> >> Gen9 has had demonstrated cases where forcing a not ready gpu
> >> into reset has caused system hang [1].
> >>
> >> Gen8 has never to th
Chris Wilson writes:
> On Fri, Oct 30, 2015 at 04:43:49PM +0200, Mika Kuoppala wrote:
>> Gen9 has had demonstrated cases where forcing a not ready gpu
>> into reset has caused system hang [1].
>>
>> Gen8 has never to this date demonstrated such behaviour.
>>
>> In our CI tests bsw sometimes end
On Fri, Oct 30, 2015 at 04:43:49PM +0200, Mika Kuoppala wrote:
> Gen9 has had demonstrated cases where forcing a not ready gpu
> into reset has caused system hang [1].
>
> Gen8 has never to this date demonstrated such behaviour.
>
> In our CI tests bsw sometimes ends up in a state where it claims
Gen9 has had demonstrated cases where forcing a not ready gpu
into reset has caused system hang [1].
Gen8 has never to this date demonstrated such behaviour.
In our CI tests bsw sometimes ends up in a state where it claims it
is not ready for reset, based on reset request, after gpu hang.
Allow
On Fri, Oct 30, 2015 at 03:18:30PM +0200, David Weinehall wrote:
> @@ -931,16 +930,20 @@ run_basic_modes(const struct access_mode *mode,
> struct buffers buffers;
>
> for (h = hangs; h->suffix; h++) {
> - if (!all && *h->suffix)
> - continue;
> +
On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> This series eliminates all spurious PCH FIFO underrun reports on my
> machines during a BAT run ('-t basic -x reload -x suspend' actually).
> It also eliminates the non-spurious but expected underrun reports
> on I
Chris Wilson writes:
> Ringbuffers are now being written to either through LLC or WC paths, so
> treating them as simply iomem is no longer adequate. However, for the
> older !llc hardware, the hardware is documentated as treating the TAIL
> register update as serialising, so we can relax the bar
Until now we've had no unified way to handle slow/combinatorial tests.
Most of the time we don't want to run slow/combinatorial tests, so this
should remain the default, but when we do want to run such tests,
it has been handled differently in different tests.
This patch adds an --all command line
Some subtests are not run by default, for various reasons;
be it because they're only for debugging, because they're slow,
or because they are not of high enough quality.
This patch aims to introduce a common mechanism for categorising
the subtests and introduces a flag (--all) that runs/lists all
When gem_concurrent_blit was converted to use the new common framework
for choosing whether or not to include slow/combinatorial tests,
gem_concurrent_all became superfluous. This patch removes it.
Signed-off-by: David Weinehall
---
tests/.gitignore |1 -
tests/Makefile.sources
We'll both rename gem_concurrent_all over gem_concurrent_blit
and change gem_concurrent_blit in this changeset. To make
this easier to follow we first do the the rename.
Signed-off-by: David Weinehall
---
tests/gem_concurrent_blit.c | 1116 ++-
1 file chan
Reported-by: Keith Webb
Suggested-by: Keith Webb
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106671
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/i
Chris Wilson writes:
> On Fri, Oct 30, 2015 at 01:39:24PM +0200, Mika Kuoppala wrote:
>> commit def0c5f6b0cd ("drm/i915: Map the ringbuffer using WB on LLC machines")
>> enhanced ringbuffer access by vmapping the object instead of doing ioremap.
>>
>> The address space annotations however have b
On Fri, 30 Oct 2015, Ville Syrjälä wrote:
> On Fri, Oct 30, 2015 at 12:06:09PM +0200, Jani Nikula wrote:
>> On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä
>> >
>> > We get spurious PCH FIFO underruns if we enable the reporting too soon
>> > after enabling the c
On Fri, Oct 30, 2015 at 12:11:45PM +0200, Jani Nikula wrote:
> On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Doing the IBX transcoder B workaround causes underruns on
> > pipe/transcoder A. Just hide them by disabling underrun reporting for
> > pipe A ar
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 364b19868ecd11b91d83c921b55022f70c6c64c6
commit: f68b2f3ac407ca71bd0b22a88127087e0842862a [3/6] drm/imx: Remove local
fbdev emulation Kconfig option
config: m68k-allyesconfig (attached as .config)
reproduce:
wget
https
On Fri, Oct 30, 2015 at 12:06:09PM +0200, Jani Nikula wrote:
> On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We get spurious PCH FIFO underruns if we enable the reporting too soon
> > after enabling the crtc. Move it to be the last step, after the encode
On Fri, Oct 30, 2015 at 09:55:03AM -0200, Paulo Zanoni wrote:
> 2015-10-30 5:56 GMT-02:00 David Weinehall :
> > On Wed, Oct 28, 2015 at 02:12:15PM -0200, Paulo Zanoni wrote:
> >> 2015-10-28 9:29 GMT-02:00 David Weinehall
> >> :
> >> > Some tests should not be run by default, due to their slow,
> >
2015-10-30 5:56 GMT-02:00 David Weinehall :
> On Wed, Oct 28, 2015 at 02:12:15PM -0200, Paulo Zanoni wrote:
>> 2015-10-28 9:29 GMT-02:00 David Weinehall :
>> > Some tests should not be run by default, due to their slow,
>> > and sometimes superfluous, nature.
>> >
>> > We still want to be able to r
On Fri, Oct 30, 2015 at 01:39:24PM +0200, Mika Kuoppala wrote:
> commit def0c5f6b0cd ("drm/i915: Map the ringbuffer using WB on LLC machines")
> enhanced ringbuffer access by vmapping the object instead of doing ioremap.
>
> The address space annotations however have been and should
> remain to be
On 30/10/15 11:26, Mika Kuoppala wrote:
VMA offsets are 64 bits. Plane surface offsets are in ggtt and
the hardware register to set this is thus 32 bits. Be explicit
about these and convert carefully to from vma to final size.
This will make sparse happy by not creating 32bit pointers out
of 64
commit def0c5f6b0cd ("drm/i915: Map the ringbuffer using WB on LLC machines")
enhanced ringbuffer access by vmapping the object instead of doing ioremap.
The address space annotations however have been and should
remain to be __iomem, in order to get warnings if we
dereference the virtual addresse
RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
configuration registers. If those are not setup Driver should not enable RC6.
For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
to know if BIOS has enabled HW/SW RC6.
This will also enable user to control RC6
VMA offsets are 64 bits. Plane surface offsets are in ggtt and
the hardware register to set this is thus 32 bits. Be explicit
about these and convert carefully to from vma to final size.
This will make sparse happy by not creating 32bit pointers out
of 64bit vma offsets.
Cc: Tvrtko Ursulin
Signe
On Thu, Oct 29, 2015 at 02:27:32PM +0200, Ander Conselvan De Oliveira wrote:
> On Thu, 2015-10-29 at 11:03 +0200, Jani Nikula wrote:
> > Cc: Yetunde Adebisi
> > Signed-off-by: Jani Nikula
> > ---
> > include/drm/drm_dp_helper.h | 36
> > 1 file changed, 36 in
On 30/10/15 01:44, Vivek Kasireddy wrote:
The main goal of this subtest is to trigger the following warning in
the function i915_gem_object_get_fence():
if (WARN_ON(!obj->map_and_fenceable))
To trigger this warning, the subtest first creates a Y-tiled object and
an associated framebuffe
On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Doing the IBX transcoder B workaround causes underruns on
> pipe/transcoder A. Just hide them by disabling underrun reporting for
> pipe A around the workaround.
>
> It might be possible to avoid the underruns by m
On Thu, Oct 29, 2015 at 04:23:45PM -0700, Rafael Antognolli wrote:
> This module is heavily based on i2c-dev. Once loaded, it provides one
> dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
>
> It's possible to know which connector owns this aux channel by looking
> at the re
On Thu, 29 Oct 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We get spurious PCH FIFO underruns if we enable the reporting too soon
> after enabling the crtc. Move it to be the last step, after the encoder
> enable. Additionally we need an extra vblank wait, otherwise we sti
On Thu, 29 Oct 2015, "Sharma, Shashank" wrote:
> HI Jani,
> I am getting this warning, from kbuild, for the new flags being added in the
> patch series in CRTC state.
>>> include/drm/drm_crtc.h:314: warning: No description found for parameter
>>> 'color_correction_changed'
>
> Can you please hel
On Thu, Oct 29, 2015 at 06:54:38PM -0700, Vivek Kasireddy wrote:
> While pinning a fb object to the display plane, only install a fence
> if the object is using a normal view. This corresponds with the
> behavior found in i915_gem_object_do_pin() where the fencability
> criteria is determined only
On 10/29/2015 10:49 PM, Pavel Machek wrote:
> On Sun 2015-10-04 18:30:14, Toralf Förster wrote:
>> On 08/04/2015 02:29 PM, Toralf Förster wrote:
>>> On 08/02/2015 09:43 AM, Pavel Machek wrote:
Any chance to bisect it?
>>> Did it.
>>>
>>> FWIW: the mentioned commit was introduced between 3.18 a
On Wed, Oct 28, 2015 at 02:12:15PM -0200, Paulo Zanoni wrote:
> 2015-10-28 9:29 GMT-02:00 David Weinehall :
> > Some tests should not be run by default, due to their slow,
> > and sometimes superfluous, nature.
> >
> > We still want to be able to run these tests in some cases.
> > Until now there's
On Wed, Oct 28, 2015 at 05:14:28PM +, Thomas Wood wrote:
> If this is intended to be documented and used in tests, then it should
> be included in the public API (i.e. without the underscore prefix).
True. Will fix.
> > + *
> > + * This is used to skip subtests that should only be included
>
77 matches
Mail list logo