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=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,USER_AGENT_MUTT 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 A586FC43381 for ; Tue, 5 Mar 2019 19:36:53 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7738120652 for ; Tue, 5 Mar 2019 19:36:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="b6JBanTE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7738120652 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1yIQ9ZyDu4PqURc0uP3Z8OVSNmGAPpjDgpFClXvg6YY=; b=b6JBanTEQ3Z0FM RNpTLViYteITT7ihEsGeBb4JRiKKc7QWphPevUeJwnh1zlGGd0+FsVrNcbjWAPRfu/tZvu2Pfz+Y+ shFnfA8N6Fq0M/muYb2vvP51QceM375y7aRxi2T7AswFTMiQdHMpMk9g6+L7B5SlYAFnx5ytZNWqU 6pfpjvbK/odIUUOlfO08nmDcH/TZvFapUCdtVf0xov1Mtz5k/kAxwoGujD8+k52Wt6PHNjobJAJ20 Ay+GKVz9CpzOYKuj650v5Xrh1U5RiCHaiX/8k4HTYeD6gtghIjH1bL9v3Ci6/7m/G4qth5FvD/jZ9 BeBtf9oBGRJlj5YynOiw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h1Frs-0008M6-6b; Tue, 05 Mar 2019 19:36:48 +0000 Received: from mga05.intel.com ([192.55.52.43]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h1Fro-0008Li-OL for linux-arm-kernel@lists.infradead.org; Tue, 05 Mar 2019 19:36:46 +0000 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 11:36:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,445,1544515200"; d="scan'208";a="121242684" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga006.jf.intel.com with SMTP; 05 Mar 2019 11:36:39 -0800 Received: by stinkbox (sSMTP sendmail emulation); Tue, 05 Mar 2019 21:36:38 +0200 Date: Tue, 5 Mar 2019 21:36:38 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Alex Deucher Subject: Re: [PATCH 2/7] drm/edid: Allow to ignore the audio EDID data Message-ID: <20190305193638.GB3888@intel.com> References: <4914bea9fc3ef3deaffa39ab691dbd9a76461e97.1551711042.git-series.maxime.ripard@bootlin.com> <87wole76ws.fsf@anholt.net> <20190305091240.sbkvdwosocaytx22@flea> <20190305152413.GD16917@intel.com> <20190305191554.GA3888@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190305_113644_801880_71ED4C17 X-CRM114-Status: GOOD ( 28.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, eben@raspberrypi.org, Maxime Ripard , Takashi Iwai , Maling list - DRI developers , Paul Kocialkowski , David Airlie , Sean Paul , Thomas Petazzoni , Daniel Vetter , linux-arm-kernel Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Mar 05, 2019 at 02:21:04PM -0500, Alex Deucher wrote: > On Tue, Mar 5, 2019 at 2:15 PM Ville Syrj=E4l=E4 > wrote: > > > > On Tue, Mar 05, 2019 at 05:24:13PM +0200, Ville Syrj=E4l=E4 wrote: > > > On Tue, Mar 05, 2019 at 10:12:40AM +0100, Maxime Ripard wrote: > > > > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote: > > > > > On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrot= e: > > > > > > > > > > > > Maxime Ripard writes: > > > > > > > > > > > > > In some cases, in order to accomodate with displays with poor= EDIDs, we > > > > > > > need to ignore that the monitor alledgedly supports audio out= put and > > > > > > > disable the audio output. > > > > > > > > > > > > > > Signed-off-by: Maxime Ripard > > > > > > > --- > > > > > > > drivers/gpu/drm/drm_edid.c | 8 ++++++++ > > > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm= _edid.c > > > > > > > index 990b1909f9d7..c0258b011bb2 100644 > > > > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > > > > @@ -4190,6 +4190,11 @@ bool drm_detect_hdmi_monitor(struct ed= id *edid) > > > > > > > } > > > > > > > EXPORT_SYMBOL(drm_detect_hdmi_monitor); > > > > > > > > > > > > > > +static bool ignore_edid_audio =3D false; > > > > > > > +module_param(ignore_edid_audio, bool, 0644); > > > > > > > +MODULE_PARM_DESC(ignore_edid_audio, > > > > > > > + "Ignore the EDID and always consider that a mo= nitor doesn't have audio capabilities"); > > > > > > > + > > > > > > > /** > > > > > > > * drm_detect_monitor_audio - check monitor audio capability > > > > > > > * @edid: EDID block to scan > > > > > > > @@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct ed= id *edid) > > > > > > > bool has_audio =3D false; > > > > > > > int start_offset, end_offset; > > > > > > > > > > > > > > + if (ignore_edid_audio) > > > > > > > + goto end; > > > > > > > + > > > > > > > edid_ext =3D drm_find_cea_extension(edid); > > > > > > > if (!edid_ext) > > > > > > > goto end; > > > > > > > > > > > > It looks like the motivation for the original flag on Raspberry= Pi was > > > > > > "I've got a non-audio monitor, but the system comes up trying t= o play > > > > > > audio to HDMI instead of the analog jack". Do we have some way= for DRM > > > > > > to communicate to ALSA that this is not the right place to try = to play > > > > > > audio by default? > > > > > > > > > > Apparently not. We have users using debug knobs in our drivers to > > > > > disable display audio because ALSA defaults to that rather than o= ther > > > > > audio. > > > > > > > > I guess one way to do this would be to register the card only when = an > > > > audio-capable monitor is connected instead of doing this at probe > > > > time. I'm not sure how convenient it is for userspace though. > > > > > > We already provide the ELD to alsa. I'm pretty sure pulseaudio uses > > > that stuff somehow to figure out whether to play audio over HDMI. > > > But since I don't use pulseaudio myself I can't be 100% sure. > > > > > > Cc:ing Takashi/alsa folks for confirmation. > > > > I forgot that the .pin_eld_notify() stuff is i915 specific. But > > I see some kind of hdmi_codec_ops thing used by some other drivers. > > I guess that is supposed to achieve the same thing more or less? > > I'm not immediately seeing any kind of drm->alsa notification > > hook in there though. > = > On AMD hw, the GPU has backdoor access to some of the audio state, so > when stuff happens on the GPU side, it's reflected on the audio side > automatically. Right. i915 has a similar thing (my theory is that it's basically an industry wide hardware workaround for inflexible Windows driver architecture). But that was problematic for some power management related reasons (IIRC) so we added a software mechanism for it. Though I believe we still write the ELD into the hardware buffer as well. -- = Ville Syrj=E4l=E4 Intel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel