Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757398AbcCURJh (ORCPT ); Mon, 21 Mar 2016 13:09:37 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:33564 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757100AbcCURI6 (ORCPT ); Mon, 21 Mar 2016 13:08:58 -0400 From: Andreas Dannenberg To: , CC: Andreas Dannenberg , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Subject: [PATCH v2 0/2] ASoC: codecs: add support for TAS5720 digital amplifier Date: Mon, 21 Mar 2016 12:08:25 -0500 Message-ID: <1458580107-4632-1-git-send-email-dannenberg@ti.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2913 Lines: 55 Driver for TI's TAS5720L/M digital audio amplifiers. The driver should be pretty standard except the optional interrupt-based fault reporting. Some background on the fault reporting since that might be a discussion of interest. The code should have that documented rather well but I wanted to bring it up right away. The TAS5720 devices can report conditions such as over-current (short), over temp, and others that can be important to know in a real-world system. However the device lacks a way to mask the generation of fault interrupts except by shutting it down, which can lead to cases where the device generates SAIF-fault host interrupts every 300us! This is clearly a lot of overhead to be thrown at the SoC (and my bench testing has demonstrated that) so after trying different things to tame this behavior I ended up implementing method to disable/enable the interrupts in the driver itself in combination with rate-limiting the processing of those events. The fact of processing interrupts in a threaded fashion (IRQF_ONESHOT) alone was not enough under certain conditions to prevent the SoC from not being able to get to all interrupts even with an empty threaded handler, and it would freeze and eventually the Kernel would disable the interrupt ("no one cared"). The scheme currently implemented seems to work reliably cycling different audio files over hours also forcing error conditions. But if anybody has a "cleaner" idea how to rate-limit IRQs on a very low level (currently done in the IRQ handler function) I'm absolutely open to suggestions. This all may not be an issue at all when using a faster/lower-latency SoC than what I'm using (BeagleBone Black) but the fact that IRQF_ONESHOT alone was not enough to prevent the system to be brought to its knees (again, even with an empty threaded handler) was a bit of a surprise to me. -- Andreas Dannenberg Texas Instruments Inc Changes since v1: - Simplified DT interrupt documentation (Thanks Rob Herring) - Fixed potential race condition during codec probe where deferred work that's used by the threaded IRQ handler was setup after the IRQ was initialized (would lead to an issue when the TAS5720 was already throwing interrupts at the time of probe) Andreas Dannenberg (2): ASoC: codecs: add TA5720 digital amplifier DT bindings ASoC: codecs: add support for TAS5720 digital amplifier .../devicetree/bindings/sound/tas5720.txt | 37 ++ sound/soc/codecs/Kconfig | 10 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tas5720.c | 734 +++++++++++++++++++++ sound/soc/codecs/tas5720.h | 90 +++ 5 files changed, 873 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tas5720.txt create mode 100644 sound/soc/codecs/tas5720.c create mode 100644 sound/soc/codecs/tas5720.h -- 2.6.4