Reviewed-by: Marc Herbert
Thx Nathan, I think this helps. I'm still curious how training normally
converges much faster than the total number of possibilities but - unlike
this latest clarification below - I expect the spec(s) to document that.
On 24/07/2018 15:33, Nathan Ciobanu
Compliance aside I had a really hard time understanding the gap between 80
and 10. I mean if up to 80 tries might be needed pre-1.4, then how come 1.4
is supposed to succeed in less than 10? Confusing.
After asking Nathan and DK (thx) I suggest rephrasing the comment below with
something like thi
>> I think the bug is with this infinite loop which is at the mercy of an
>> external device
>> and in my case I have this MST hub which appears to be DP 1.2 that triggers
>> the
>> infinite loop case. We have to limit the number of iterations and
>> DP 1.4 spec happened to fix this issue. I'm a
While the shortness of v3 is really nice, I think it's rather a good
opportunity to make much clearer (as a separate, no functional change
patch?) its existing terminating condition(s) and what the existing loop
iterates on. I mean it's painful and risky enough to _combine multiple
counters in th
Hi Jani,
> *cringe* at adding a parameter to workaround issues.
I understand that *each* parameter has the potential to *multiply* the total
number of configurations and that the resulting combinatorial explosion is
absolutely not scalable and sustainable from a validation perspective. No
one sho
[I'm cheating and doing this code review with the author watching over my
shoulder]
On 11/02/16 15:22, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Track VCO frequency of SKL instead of the boot CDCLK and allow modeset
> to set cdclk based on the max required pixel clock based on
On 10/02/16 06:27, Ville Syrjälä wrote:
> On Tue, Feb 09, 2016 at 04:28:27PM -0800, clinton.a.tay...@intel.com wrote:
>> From: Clint Taylor
>>
>> Track VCO frequency of SKL instead of the boot CDCLK and allow modeset
>> to set cdclk based on the max required pixel clock based on VCO
>> selected.
>
> On machines that had 1.19 symlinked, in filesystem, execlist submission
> sometimes broke due to interrupt delivery problem. To reach a conclusion
> that it was csr firmware, before 1.21 was out, took quite amount of work.
>
> I bet there are still machines with 1.19 only, and we get to
> wade t
On 30/09/15 07:28, Imre Deak wrote:
On ke, 2015-08-26 at 16:58 +0530, Animesh Manna wrote:
-void i915_firmware_load_error_print(const char *fw_path, int err)
-{
- DRM_ERROR("failed to load firmware %s (%d)\n", fw_path, err);
-
- /*
-* If the reason is not known assume -ENOEN
_linearized_ i915 forklift for ChromeOS.)
Signed-off-by: Marc Herbert
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 177f7ed16cf0..1c14233d179f 100644
The bare "Test requirement: modes" message is too cryptic, I had to go and
read the source code to understand the missing requirement.
Signed-off-by: Marc Herbert
---
If there is a different message that you would like to push yourself
then please don't mind me - I think ANY m
Required to run on any recent, freon-based and X11-free ChromeOS release.
Signed-off-by: Marc Herbert
---
Changes from v1:
- igt_debug() instead of igt_warn()
- return KD_GRAPHICS instead of -1UL
- print previous mode in debug statements. Among others this help a tiny
bit with the now
current patch. But if someone can think of a silver and
relatively cheap bullet that would suit all usecases then please let
me/us know ASAP.
Cheers,
Marc
Marc Herbert (1):
lib/igt_kms.c: remove tests dependency on VT /dev/tty0
lib/igt_kms.c | 20 +---
1 file changed,
Required to run on any recent, freon-based and X11-free ChromeOS release.
Signed-off-by: Marc Herbert
---
lib/igt_kms.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index d0c3690..27cff86 100644
--- a/lib/igt_kms.c
+++ b
14 matches
Mail list logo
