From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Mack Subject: Re: [PATCH] ALSA: ASoC: add codec driver for TI TAS5086 Date: Wed, 22 May 2013 19:55:22 +0200 Message-ID: <519D068A.8030003@gmail.com> References: <1362740833-15704-1-git-send-email-zonque@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by alsa0.perex.cz (Postfix) with ESMTP id 6D0CB260899 for ; Wed, 22 May 2013 19:55:02 +0200 (CEST) Received: by mail-bk0-f50.google.com with SMTP id ik8so328545bkc.23 for ; Wed, 22 May 2013 10:55:02 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: "jonsmirl@gmail.com" Cc: alsa-devel mailing list , Mark Brown , lgirdwood@gmail.com List-Id: alsa-devel@alsa-project.org On 22.05.2013 19:50, jonsmirl@gmail.com wrote: > On Fri, Mar 8, 2013 at 6:07 AM, Daniel Mack wrote: >> This patch adds a driver for TI's TA5086 6-channel PWM processor. >> >> This chip has a very unusual register layout, specifically because the >> registers are of unequal size, and multi-byte registers require bulk >> writes to take effect. Regmap does not support these kind of mappings. >> >> Currently, the driver does not touch any of the registers >= 0x20, so >> it doesn't matter, because the register map is mapped to an 8-bit array. >> In case more features will be added in the future that require access >> to higher registers, the entire regmap H/W I/O routines have to be >> open-coded. > > Check out my tas5504 driver from a long time ago. It dealt with those registers. > > https://github.com/jonsmirl/mpc5200/blob/master/sound/soc/codecs/tas5504.c > https://github.com/jonsmirl/mpc5200/blob/master/sound/soc/codecs/tas5504.h Sure, without any regmap abstractions, things are somehow manageable. Though you lose all the nice things that regmap gives you, such as hardware independence and caching. I might have a different solution, but I need to get my hands on one of these devices to test. On a slightly different note: why isn't your driver in the mainline kernel? Thanks, Daniel