Received: by 10.192.165.148 with SMTP id m20csp3770242imm; Mon, 23 Apr 2018 12:02:36 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+ZJDAiSiUNVtfbZ31sB/KufCehXsiDToAy3hAoabyUNJLl0G5xkOB7il0gjlPHCg4K6/Xu X-Received: by 10.167.133.12 with SMTP id v12mr10166781pfn.90.1524510156268; Mon, 23 Apr 2018 12:02:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524510156; cv=none; d=google.com; s=arc-20160816; b=vT417bXMb6E+OOeQXV8+QVLDhAPS+zbfPzJ3uCNDUHCV4Gsbu7Y4ALuHKOO2/Lf5sv 6MLHB/KxoVILm+/7ycXkPhqcfSEZ8cv5OsmRTDRbPgGZ4xElS9wJshdZ5XdlU7t7ds7c 6lYxnbFUF+AC5C3DAWNuDjVSItaRXqf2JeFV8mlI5kfAKZAKWBRoSxQzZtM6yPBDWCjQ LI9yisFXfEOrebIIISn+Zgwzu3piW9uhv/pdofS9w1MpeWrze9on6fTyjN2OYv2+phXo Z6R63WG2S7z5RGWEV34IKg1EAgV0+Ee9S2s/B1cWczD3Hsdow0USHudWQK0SDQg/n7Xz ahhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=KS3QnqfDKZegvk0PVMsl2htMwD/yCUHEIqbvD75H4Ts=; b=UWIZkgrFvCyKjfF+Tr0AeOsZnC3WbFH3f8xnXjM6/nphtWYGwtsGGNBZAmteJCwL1V 6dOVzZOyTEyvCOlEZS45eKbekXOoACyA+Vw9iQfpkE9dv+rEuBXllozQuB+jtV//bfKW ttyAA7LGy38HJCfc90KtROyVSLcpRsrzLyWOh4jFBWQy1RcdTbNNjqQIUXEZWw7LQ70q +amosvzqGRRZOqLKLM2nVftJMJMURhTSENjNnd4GKMskB/6vYOLFzwTRw5GchFLLTGnY hndwnI2XE0rJH6ngzFoOZ3xpWEWBT/1icrwckWwloxtxF/8vOegW9CZrXho0f5Yh9Cmh kybw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=uLfkqNq9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y9si10382896pgp.525.2018.04.23.12.02.21; Mon, 23 Apr 2018 12:02:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=uLfkqNq9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932350AbeDWTAo (ORCPT + 99 others); Mon, 23 Apr 2018 15:00:44 -0400 Received: from lelnx193.ext.ti.com ([198.47.27.77]:38632 "EHLO lelnx193.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932298AbeDWTAm (ORCPT ); Mon, 23 Apr 2018 15:00:42 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by lelnx193.ext.ti.com (8.15.1/8.15.1) with ESMTP id w3NJ0Owk027454; Mon, 23 Apr 2018 14:00:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1524510024; bh=ZtypOFPVr+4EtaGZF3GiSTOl+XSzF+ixVjsEkSZ4Jko=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=uLfkqNq9ULUL+fp8aguecTAiXAm+WDAi4ctWk0ljN8fy744r6/TMyqOPaCg80AWNN 8sjtTeoHkPX1bR+e5bBVyXBjSp2F3MgvlCt5FObbKGqUsJVyD42D3GnLhvSEH5iF+v jFxcbp6+iQufUPunUha8QYK6S/kpMMnULMXMLmYw= Received: from DFLE109.ent.ti.com (dfle109.ent.ti.com [10.64.6.30]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w3NJ0Omj015065; Mon, 23 Apr 2018 14:00:24 -0500 Received: from DFLE115.ent.ti.com (10.64.6.36) by DFLE109.ent.ti.com (10.64.6.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 23 Apr 2018 14:00:24 -0500 Received: from dflp33.itg.ti.com (10.64.6.16) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1466.3 via Frontend Transport; Mon, 23 Apr 2018 14:00:24 -0500 Received: from [172.22.190.2] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w3NJ0Jra025323; Mon, 23 Apr 2018 14:00:20 -0500 Subject: Re: [PATCH 1/3] ASoC: tas6424: Allow disabling auto diagnostics for faster power-on To: Mark Brown CC: , , , , , , , , References: <1524218684-19752-1-git-send-email-jjhiblot@ti.com> <1524218684-19752-2-git-send-email-jjhiblot@ti.com> <20180423154411.GK19834@sirena.org.uk> From: Jean-Jacques Hiblot Message-ID: Date: Mon, 23 Apr 2018 21:00:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180423154411.GK19834@sirena.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/04/2018 17:44, Mark Brown wrote: > On Fri, Apr 20, 2018 at 12:04:42PM +0200, Jean-Jacques Hiblot wrote: >> The TAS6424 incorporates both DC-load and AC-load diagnostics which are >> used to determine the status of the load. The DC diagnostics runs when any >> channel is directed to leave the Hi-Z state and enter the MUTE or PLAY >> state. >> The DC diagnostics are turned on by default but if a fast startup without >> diagnostics is required the DC diagnostics can be bypassed by adding the >> property "disable-auto-diagnostics". > This is making me think we should be smarter here and either only run > the diagnostics once during boot or provide a user control for the > diagnostics. It seems like something that is more of a runtime software > decision than something that's fixed in hardware design, is there > anything about the hardware design that'd make it impossible to run > diagnostics? I can't think of anything that would make it unusable. This auto diagnostic is really useful in cars where wires can get disconnected or shorted to ground. In quieter environment it may not be as useful, and a test at startup may be sufficient. Diagnostics can also be triggered at will. Do you think a sysfs interface would be better suited to disable the autodiag ? Thanks for your comment on the series. JJ > >> + if (tas6424->no_auto_diags) { >> + /* >> + * Disable DC auto-diagnostics to save time when channel leave >> + * Hi-Z state >> + */ >> + ret = regmap_update_bits(tas6424->regmap, >> + TAS6424_DC_DIAG_CTRL1, >> + 0xff, TAS6424_LDGBYPASS); > This could just be exposed to userspace as a simple switch control > couldn't it? I do note that it masks more bits than it sets though...