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 ECCCAC43381 for ; Mon, 4 Mar 2019 15:59:45 +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 BDE6A206B6 for ; Mon, 4 Mar 2019 15:59:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kkdYXhiB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BDE6A206B6 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=s6pzWnJrPham+fkqfEZ/DwFzpaVmFcCOosfFl6kX+sA=; b=kkdYXhiBrsVfjH Xa4s+Bma1e0JHYzpuy+jvurLc4bGP8Dd/FC3k1eYP9H59977v1gtQNB4kpjQ3RbIgWfxBbopmf2Rs B/hfk+kc44TSGS8HjmcmgyzKiuTmNVSLEU0x93nuBiz4LCHEEXoTorqj7NIXNdrjxsbwTroEd+Kjw MBonQOh67ToRpfJEF/8BHHfSdJ6FztQkw6ab4cxe2CqkBHiXpunS835R13eGxn43fgZ4ignr9Fn5J KMFqoUfM+I/OqfcWPD3Rg+ENMHk6/p/OrxgrWaI/8j9mqCZDCKzNaQcsGtol+BOlvMGtcNGtbmen1 5i1Fy8gUdq8tGLSLLyNA==; 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 1h0q0D-00038f-2M; Mon, 04 Mar 2019 15:59:41 +0000 Received: from mga12.intel.com ([192.55.52.136]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h0q09-00038I-DU for linux-arm-kernel@lists.infradead.org; Mon, 04 Mar 2019 15:59:39 +0000 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 07:59:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,440,1544515200"; d="scan'208";a="148460740" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by fmsmga002.fm.intel.com with SMTP; 04 Mar 2019 07:59:32 -0800 Received: by stinkbox (sSMTP sendmail emulation); Mon, 04 Mar 2019 17:59:31 +0200 Date: Mon, 4 Mar 2019 17:59:31 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Maxime Ripard Subject: Re: [PATCH 2/7] drm/edid: Allow to ignore the audio EDID data Message-ID: <20190304155931.GW20097@intel.com> References: <4914bea9fc3ef3deaffa39ab691dbd9a76461e97.1551711042.git-series.maxime.ripard@bootlin.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4914bea9fc3ef3deaffa39ab691dbd9a76461e97.1551711042.git-series.maxime.ripard@bootlin.com> 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-20190304_075937_467875_765595FF X-CRM114-Status: GOOD ( 21.63 ) 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: eben@raspberrypi.org, David Airlie , Maarten Lankhorst , dri-devel@lists.freedesktop.org, Paul Kocialkowski , Sean Paul , Thomas Petazzoni , Daniel Vetter , linux-arm-kernel@lists.infradead.org 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 Mon, Mar 04, 2019 at 03:52:35PM +0100, Maxime Ripard wrote: > In some cases, in order to accomodate with displays with poor EDIDs, we > need to ignore that the monitor alledgedly supports audio output 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 edid *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 monitor doesn't have audi= o capabilities"); > + I would suggest that this is not the best apporach. Years of experience from i915 says that more modparams means random forums full of people trading cargo culted settings. And as soon as the average user comes across the magic incantation that works they are likely to not file the appropriate bug report. Also years later we still see people using modparams that stopped working five hardware generations ago. So at least for i915 new modparams are generally frowned upon. Bad EDIDs at least should be quirked. Which means we really need the bug reports, and hence a modparam can be somewhat counter productive. For allowing the user to force the DVI vs. HDMI and audio vs. not i915 does have the "audio" connector property. Other drivers could adopt the same thing. Though I'm not sure even i915 should be exposing this for the reasons already mentioned. There is one hardware generation where it can actually be useful on i915 as the hardware is only capably of sending infoframes/audio to a single HDMI port at a time. So with this property the user can at least select which display gets to do those things. I do agree that there is an unfortnate problem with fbcon vs. initial property values. I've sometimes pondered about exposing kms properties in a generic fashion via sysfs and/or kernel cmdline somehow. IIRC devicetree/something similar has also been proposed occasionally to solve this problem. > /** > * drm_detect_monitor_audio - check monitor audio capability > * @edid: EDID block to scan > @@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct edid *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; > -- = > git-series 0.9.1 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- = 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