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=-2.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED, USER_AGENT_NEOMUTT 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 B46DEC4360F for ; Thu, 28 Feb 2019 12:15:33 +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 8342B214D8 for ; Thu, 28 Feb 2019 12:15:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="d7qLpy18"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="tprmcGmO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8342B214D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk 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:MIME-Version: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:In-Reply-To:References: List-Owner; bh=YKCuxEtcch+EEW65emocVT4CyZC3YAJyIerGd3C/kR0=; b=d7qLpy18i41kGB FbJRlTZihMHXuzZ1lgs/WzOPCRAm46BYLvWVyBx+D5SlsPjNHvUfRfptAtVCl015TW60aea0m+jFW +3njgb9Xm7PVQhCZ3ZGmQdhZ4dnKv6yJs0L6h46/wpBRgkwx4gA5LLlq4O1jZEVVUTHr6OSZR1SUC NTTr1DRBvai8qtkiJ1ah6R6iaXuXhkliEOMO8iRrWRRCQw5x3OLXeUkWkGnJFTLkUmqbBuTwgv0Ov 8tRVnx058IJ1vVoTkyvhimXaGQwf0us3frt+XascrHlgJTGAFM9d9WQeRNKsenUbl1u9mcwhfxCXz zsy3uZDKZOil0cY+rnxQ==; 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 1gzKb5-000790-Uh; Thu, 28 Feb 2019 12:15:31 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gzKb1-00078i-PT for linux-arm-kernel@lists.infradead.org; Thu, 28 Feb 2019 12:15:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:Content-Type:MIME-Version: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=p0W9HcQqab7nM5jJ/dzDgwg4tVnj5Fdz9Bwq8WtH2Eg=; b=tprmcGmOwFHuiZWgYYK371Y8m vZmNWCdoLBzNKAfofxnzhxcA2XfHK2HsjGZyf8ldJprZe5oAdUEtGcUwi3nqnvGuQdWMNv9wiTVwv S0T6q5q2FoIwKrj678JyQe7ALoCnnrZIarurvV/BkSWi/bHuTubd1hsjk4InAnHqWlvcf69mA1Wjj q7HZwnljZQcuC//S72lQme4/s9qH+ikopsDtWcXE4U2bTKb60Bnfg1/PVSbMwbb7B8sRQp64oK2lt lJkdVBn4qzNtZq6G1vPHdsS+boIdLdseImPhH2TtGnTInv5zn42m/r1S94ZrhPB/YWh4lEMcKI+90 BgGDl/ftA==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:37170) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gzKat-0000Eb-6p; Thu, 28 Feb 2019 12:15:19 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.89) (envelope-from ) id 1gzKaq-0007O0-Kr; Thu, 28 Feb 2019 12:15:16 +0000 Date: Thu, 28 Feb 2019 12:15:16 +0000 From: Russell King - ARM Linux admin To: Jyri Sarha , Liam Girdwood , Mark Brown Subject: hdmi-codec: modifying params in hw_params() callback Message-ID: <20190228121516.swd3vweisgcxlvld@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190228_041527_825662_72E4A207 X-CRM114-Status: UNSURE ( 9.28 ) X-CRM114-Notice: Please train this message. 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, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi all, While looking at hdmi-codec issues, I spotted this code: static int hdmi_codec_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params, struct snd_soc_dai *dai) { ... if (params_width(params) > 24) params->msbits = 24; params->msbits is a parameter that is negotiated and refined by libasound, and is part of the ALSA constraint system. The "Writing an ALSA driver" documentation says about the hw_params callback: "This is called when the hardware parameter (``hw_params``) is set up by the application, that is, once when the buffer size, the period size, the format, etc. are defined for the pcm substream." which suggests we should only be reading the parameters, not writing to them. What's more is that the msbits is a parameter that is refined with userspace, so surely the above should be a declared constraint? Digging a bit deeper, ASoC passes a private copy of the params to each codec - a copy is made, then fixups for TDM slots are applied, followed by any topology fixups by the DAI link (be_hw_params_fixup) before the codec driver's hw_params() callback is made. Afterwards, ASoC reads back the rate, channels and physical (memory) width and stores them in the codec's DAI structure. The msbits are not read. hdmi-codec also seems to do nothing with the msbits parameter other than the above code. So, all in all, it seems that the above code limiting msbits is redundant - nothing will read this modified value. Can we kill it? Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel