From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756272AbcECTnZ (ORCPT ); Tue, 3 May 2016 15:43:25 -0400 Received: from smtp12.smtpout.orange.fr ([80.12.242.134]:49005 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753360AbcECTnY convert rfc822-to-8bit (ORCPT ); Tue, 3 May 2016 15:43:24 -0400 X-ME-Helo: belgarion X-ME-Auth: amFyem1pay5yb2JlcnRAb3JhbmdlLmZy X-ME-Date: Tue, 03 May 2016 21:43:22 +0200 X-ME-IP: 109.220.176.123 From: Robert Jarzmik To: Mark Brown Cc: Daniel Mack , Haojian Zhuang , Jaroslav Kysela , Takashi Iwai , Liam Girdwood , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com Subject: Re: [RFC PATCH 2/7] ALSA: ac97: add an ac97 bus References: <1462050939-27940-1-git-send-email-robert.jarzmik@free.fr> <1462050939-27940-3-git-send-email-robert.jarzmik@free.fr> <20160503162938.GT6292@sirena.org.uk> X-URL: http://belgarath.falguerolles.org/ Date: Tue, 03 May 2016 21:43:20 +0200 In-Reply-To: <20160503162938.GT6292@sirena.org.uk> (Mark Brown's message of "Tue, 3 May 2016 17:29:38 +0100") Message-ID: <87twiforl3.fsf@belgarion.home> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mark Brown writes: > On Sat, Apr 30, 2016 at 11:15:34PM +0200, Robert Jarzmik wrote: >> AC97 is a bus for sound usage. It enables for a AC97 AC-Link to link one >> controller to 0 to 4 AC97 codecs. > >> The goal of this new implementation is to implement a device/driver >> model for AC97, with an automatic scan of the bus and automatic >> discovery of AC97 codec devices. > > I think this is basically what I was thinking of, yes. One thing we'll > need to do is work out how to handle systems that need some explicit > action to start clocks for the bus clock, though they were never very > common and it's entirely possible nobody cares any more so perhaps we > just punt and see if anyone notices for now. You probably mean the BITCLK clock. What is a bit pesky about this clock is that it can either be mastered by digital controller and the codec is a slave, or the other way around. So we had either the BITCLK provided by : - the controller => this could be passed in ac97_digital_controller_register() - the codec => this is trouble, I don't really know how to handle this case If the bus code has this clock, it can indeed prepare and enable it. >> +int ac97_digital_controller_register(const struct ac97_controller_ops *ops, >> + struct device *dev); >> +int ac97_digital_controller_unregister(const struct device *dev); > > Why "digital"? I copy-pasted this from Audio Codec '97 Revision 2.3, where in several places they call the controller a "digital controller". Quoting chapter 1.4: The digital link that connects the AC ‘97 Digital Controller to the AC ‘97 Codec, referred to as AC-link, is a bi- directional, 5-wire, serial time domain multiplexed (TDM) format interface. AC-link supports connections between a single Controller and up to 4 CODECs on a circuit board and/or riser card. Now if you prefer "ac97_controller" or something like that, that's as you wish, the name does not matter that much to me ;) Cheers. -- Robert