Re: [PATCH v4 01/17] mfd: madera: Add register definitions for Cirrus Logic Madera codecs

From: Lee Jones <lee.jones@linaro.org>
To: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Cc: gnurou@gmail.com, alsa-devel@alsa-project.org,
	jason@lakedaemon.net, devicetree@vger.kernel.org,
	linus.walleij@linaro.org, patches@opensource.wolfsonmicro.com,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	linux-gpio@vger.kernel.org, broonie@kernel.org,
	tglx@linutronix.de
Subject: Re: [PATCH v4 01/17] mfd: madera: Add register definitions for Cirrus Logic Madera codecs
Date: Tue, 8 Aug 2017 12:03:19 +0100	[thread overview]
Message-ID: <20170808110319.ssagukhfp72r5vys@dell> (raw)
In-Reply-To: <1501235239-11145-2-git-send-email-rf@opensource.wolfsonmicro.com>

On Fri, 28 Jul 2017, Richard Fitzgerald wrote:

> This patch adds a header file of register definitions for Cirrus
> Logic "Madera" class codecs. These codecs are all based off a common
> set of hardware IP so have a common register map (with a few minor
> device-to-device variations).
> 
> The registers.h file is tool-generated directly from the hardware design
> but has been manually stripped down to reduce size (full register
> map is >44000 lines). All names are kept the same as datasheet names
> so that they can be cross-referenced between source and datasheet without
> confusion.
> 
> The register map layout is kept fully-defined rather than factored into
> macros and/or block-indexing code. The major reasons for this are:
> 
>  - #1 is that it makes the source highly greppable, which is important.
>    "What does the driver do with register bits XYZ" or "Where does it use
>    register bits XYZ" are commonly types of questions. These can be quickly
>    answered by a grep. Squashing definitions into generator macros or block-
>    indexing code is a way of defeating grep.
> 
>  - most of the register definitions are used in tables, so a constant value
>    is required. Using generator macros make the table definition clunky and
>    obscure.
> 
>  - the code is clearer when it's there in the source exactly what register
>    and field it is using
> 
>  - it is easier to diff the register map of a new (unsupported) codec against
>    what is already supported and merge in differences
> 
>  - it makes the register map available in source for maintenance/debugging
>    instead of having to refer back to the datasheet for a register map
> 
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> Changes since V3:
> - Manually stripped out a lot more stuff, defines we're not using right now
> - Added the explanation above to the commit message of why we define the
>   map effectively verbatim
> 
>  MAINTAINERS                          |   10 +
>  include/linux/mfd/madera/registers.h | 3987 ++++++++++++++++++++++++++++++++++
>  2 files changed, 3997 insertions(+)
>  create mode 100644 include/linux/mfd/madera/registers.h

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel