From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5CBCC48BD6 for ; Wed, 26 Jun 2019 19:30:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9AA7E216FD for ; Wed, 26 Jun 2019 19:30:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="f8TY1v47" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726481AbfFZTa3 (ORCPT ); Wed, 26 Jun 2019 15:30:29 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:34202 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726239AbfFZTa2 (ORCPT ); Wed, 26 Jun 2019 15:30:28 -0400 Received: by mail-io1-f66.google.com with SMTP id k8so4455638iot.1 for ; Wed, 26 Jun 2019 12:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZMDBPgUsvp65+GDLE8L0NRSWZecIdZ0UtHWFD2Htqnw=; b=f8TY1v47mlNmVd21P8YuLUhvPcChePJhG5luDNvNOtOVM0rQxgkmqCwMDmf30Pudhf Z2bz0ZwXvpg8OX8mhH5NXCZszTpkwlUwUseq96CumbKwcURP9hZVRxWVqkhb/A+4g1V7 DEcJcWvGjKFFkLhlwMo6C03JF99srWG00HP6c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZMDBPgUsvp65+GDLE8L0NRSWZecIdZ0UtHWFD2Htqnw=; b=OsAUheY7SaYpK5/0GCn+kz1ORxy9X40MallgCgek2M++qCzXYNuyvR20Cu4YOqgvnc DsuW6PDGQnE4Vme+5tPvaSVZpTdJhaa3x/BR3LCTBwdCsiNbP9OttL91CxXYLSKXKw+s nrTZZrX7z2fH5IP5R2fU24eaBF1eYjekfmj63NMwjY/po4qtLQUYnIs1E7fQ7d6s5mGr vtuKrYe7FHfgkjSIe9m+sazJKtUtkRCrCb6gdXtetYCZ5w014IwzIv77ppT3WUkmmyM0 kEurizJCurGdPTofP8Yw5iVcn45Uvfc/LbG5sWkkynC3aX1JE9MJO0owTQ3hzuxjXMWE Fl7g== X-Gm-Message-State: APjAAAXPZ89JW6Gx1ZqemOYcLVDyG5ZSd2r+0TOPg3MDrrR1gWASdUir 4jvqxKemMCeLUv8hif4J3CaPESIqRPQ= X-Google-Smtp-Source: APXvYqwEIf3Vx+eOPtp+lY//B1U0QFNT/E09Fvha13rS77spEuiw6231i7DSWVG0xldiYEhNwPGrTw== X-Received: by 2002:a6b:3b89:: with SMTP id i131mr6484407ioa.33.1561577427995; Wed, 26 Jun 2019 12:30:27 -0700 (PDT) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com. [209.85.166.53]) by smtp.gmail.com with ESMTPSA id q1sm18552890ios.86.2019.06.26.12.30.27 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2019 12:30:27 -0700 (PDT) Received: by mail-io1-f53.google.com with SMTP id e5so4533895iok.4 for ; Wed, 26 Jun 2019 12:30:27 -0700 (PDT) X-Received: by 2002:a5e:8f08:: with SMTP id c8mr6956221iok.52.1561577085074; Wed, 26 Jun 2019 12:24:45 -0700 (PDT) MIME-Version: 1.0 References: <20190619210718.134951-1-dianders@chromium.org> In-Reply-To: From: Doug Anderson Date: Wed, 26 Jun 2019 12:24:32 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/2] drm/bridge/synopsys: dw-hdmi: Handle audio for more clock rates To: Andrzej Hajda Cc: Laurent Pinchart , Sean Paul , Jernej Skrabec , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Jonas Karlman , Maxime Ripard , Neil Armstrong , "open list:ARM/Rockchip SoC..." , Dylan Reid , Cheng-Yi Chiang , Jerome Brunet , Sam Ravnborg , dri-devel , LKML , David Airlie , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, Jun 26, 2019 at 2:56 AM Andrzej Hajda wrote: > > > AKA: anyone using auto-CTS won't notice any change > > at all. I guess the question is: with Auto-CTS should you pick the > > "ideal" 6272 or a value that allows CTS to be the closest to integral > > as possible. By reading between the lines of the spec, I decided that > > it was slightly more important to allow for an integral CTS. If > > achieving an integral CTS wasn't a goal then the spec wouldn't even > > have listed special cases for any of the clock rates. We would just > > be using the ideal N and Auto-CTS and be done with it. The whole > > point of the tables they list is to make CTS integral. > > > Specification recommends many contradictory things without explicit > prioritization, at least I have not found it. > > So we should relay on our intuition. > > I guess that with auto-cts N we should follow recommendation - I guess > most sinks have been better tested with recommended values. > > So what with non-auto-cts case: > > 1. How many devices do not have auto-cts? how many alternative TMDS > clocks we have? Maybe it is theoretical problem. > > 2. Alternating CTS in software is possible, but quite > complicated/annoying, but at least it will follow recommendation :) It is OK w/ me if we want to drop my patch. With the auto-CTS patch it shouldn't matter anymore. ...but I still wanted to post it to the list for posterity in case it is ever useful for someone else. -Doug