All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kai Vehmanen <kai.vehmanen@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
Date: Fri, 3 Jan 2020 17:28:24 +0200 (EET)	[thread overview]
Message-ID: <alpine.DEB.2.21.2001031703180.16459@zeliteleevi> (raw)
In-Reply-To: <20200102182845.GB11904@intel.com>

Hi,

On Thu, 2 Jan 2020, Rodrigo Vivi wrote:

> On Tue, Dec 31, 2019 at 04:00:07PM +0200, Kai Vehmanen wrote:
>> Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
>> CDCLK>=2*BCLK constraint to more platforms"). Audio drivers
[...]
>>  		/* Force CDCLK to 2*BCLK as long as we need audio powered. */
>> -		if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>> +		if (IS_GEMINILAKE(dev_priv))
> 
> I believe for correctness we should at least say this is for display_10 but
> since we don't have display gen defined probably the right thing to do here
> is to at least replace this per:
> 
> IS_GEN(dev_priv, 10) || IS_GEMINILAKE(dev_priv)

I checked the cdclk tables for CNL in intel_cdclk.c and minimum CDCLK
is 168kHz, so it is similar (>BCLK and close to 2*BCLK) as ICL and 
others and the workaround is not needed.

I do agree this still smells funny, but basicly my naive attempt to align 
with the spec failed in wider testing and it seems this original solution 
to have the WA for GLK only, is the least bad option at this point.

Possible longer term solutions for this: 
   (i) more clock configurations allowing to bump the freq without
       a mode change on all platforms
   (ii) avoid all HDA communication at probe time and only initialize
  	the HDA connection when a monitor is connected 
   (iii) guarantee min cdclk to be sufficient for HDA communication

Closing on feasibility of (i) and (iii) is going to be a longer 
discussion.

The (ii) option would be quite a big change on audio side and might
potentially require changes to drm_audio_component.h (and impact other
drivers). To me, this feels wrong, the HDA bus supports discovery of
codecs, so we should be able to use it as with any HDA codec, including
graphics. Unless we hit deadends with (i) and (iii), I'd rather 
not pursue this path.

Br, Kai
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-01-03 15:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-31 14:00 [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Kai Vehmanen
2019-12-31 14:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2) Patchwork
2019-12-31 20:06 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-01-02 18:28 ` [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Rodrigo Vivi
2020-01-03 15:28   ` Kai Vehmanen [this message]
2020-01-06 16:49     ` Matt Roper
2020-03-06 16:45       ` Kai Vehmanen
2020-03-09 10:54         ` Takashi Iwai
2020-03-10 11:20           ` Kai Vehmanen
2020-03-10 13:41           ` Ville Syrjälä
2020-03-10 17:18             ` Kai Vehmanen
2020-03-10 18:25               ` Ville Syrjälä
2020-03-10 19:13                 ` Takashi Iwai
2020-03-11 12:16                   ` Kai Vehmanen
     [not found]                     ` <s5hk13q7uf6.wl-tiwai@suse.de>
2020-03-11 17:04                       ` Kai Vehmanen
2020-03-11 17:21                         ` Takashi Iwai
2020-03-12 17:27                 ` Kai Vehmanen
2020-03-12 17:48                   ` Ville Syrjälä
2020-03-12 17:50                   ` Ville Syrjälä
2020-03-13 14:54                     ` Kai Vehmanen
2020-03-11 20:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3) Patchwork
2020-03-11 20:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-12 13:05 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2001031703180.16459@zeliteleevi \
    --to=kai.vehmanen@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.