From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752279AbdLASBS (ORCPT ); Fri, 1 Dec 2017 13:01:18 -0500 Received: from mail-it0-f54.google.com ([209.85.214.54]:34378 "EHLO mail-it0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751104AbdLASBO (ORCPT ); Fri, 1 Dec 2017 13:01:14 -0500 X-Google-Smtp-Source: AGs4zMay1HV/0ROpAJOvHrF2jnfpqvW4F0BAKtuBhXy2jTY/3Z/EnecLVAcuXnTTUO8hKrrBKqtO8g== MIME-Version: 1.0 In-Reply-To: <151215105956.4852.3393236663014165115@mail.alporthouse.com> References: <20171201172032.47357-1-seanpaul@chromium.org> <20171201172032.47357-3-seanpaul@chromium.org> <151215024280.1324.2765501954695029499@mail.alporthouse.com> <151215091507.4852.2176019139113860843@mail.alporthouse.com> <151215105956.4852.3393236663014165115@mail.alporthouse.com> From: Sean Paul Date: Fri, 1 Dec 2017 13:00:51 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines To: Chris Wilson Cc: dri-devel , Intel Graphics Development , David Airlie , Linux Kernel Mailing List , Rodrigo Vivi , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 1, 2017 at 12:57 PM, Chris Wilson wrote: > Quoting Chris Wilson (2017-12-01 17:55:15) >> Quoting Sean Paul (2017-12-01 17:48:17) >> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson wrote: >> > > The current wait_for() is a little more complicated nowadays (variable >> > > W). >> > > >> > >> > Hmm, am I based off the wrong tree? I'm using drm-intel-next. >> >> drm-intel-next is what was sent as a PR; drm-intel-next-queued is always >> current. To be sure CI, doesn't complain about merge conflicts, base on >> drm-tip. > Ahhhh, i forgot about -queued. ok, will rebase. > Speaking of CI, do you have any instructions on how we might set up a > test system? I'm working on an igt test for the property now. > Just needs a compatible monitor and some test code? Yep. For testing, I exposed the property via sysfs and fiddle with it that way. > Could chamelium or something like that be used as a validator? You would have to implement the receiver side of HDCP on chamelium in order for this to work. So, probably not. Sean > -Chris