linux-kernel - [v2] NXP Semiconductors TFA9879 Amplifier Driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu,  6 Nov 2014 17:39:44 +0100
From:	Peter Rosin <peda@...ator.liu.se>
To:	alsa-devel@...a-project.org
Cc:	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org,
	Peter Rosin <peda@...ntia.se>
Subject: [v2] NXP Semiconductors TFA9879 Amplifier Driver

On 2014-11-06 17:02, Mark Brown wrote:> On Thu, Nov 06, 2014 at 02:37:31PM +0000, Peter Rosin wrote:
>> > Mark Brown wrote:
>>>> > > > +	if (tfa9879->lsb_justified)
>>>> > > > +		TFA9879_REG(codec, SERIAL_INTERFACE_1, I2S_SET, i2s_set);
>>> > > Why does this need to be reset every time, shouldn't we just be setting the
>>> > > register in set_fmt().?
>> > Yes, I'd sure like to do that, but how do I get to the width in set_fmt()?
> Oh, this has some width related thing in it?

Yes, the amp has a different setting for each lsb-justified width.
(It also supports 18 and 20 bits wide data)

>>>> > > > +	{ TFA9879_MISC_STATUS,		0x0000 }, /* 0x15, read-only */
>>>> > > > +};
>>>> > > > +static bool tfa9879_volatile_register(struct device *dev, unsigned
>>>> > > > +int reg) {
>>>> > > > +	return reg == TFA9879_MISC_STATUS;
>>> > > If the register is volatile it shouldn't have a default value provided.
>> > Then I misunderstood what volatile was meant to do. I'll just nuke the
>> > function. It works fine anyway...
> A volatile register is one that the chip may change autonomously (eg, an
> interrupt status register).

That was what I assumed, and the register behaves like that. I naively
thought that declaring it as volatile would prevent the asoc core from
writing to it. In retrospect, I don't understand why I thought that...
Anyway, that bit can wait until someone actually needs to read the staus.

Here's an update with the following changes since v1:

- squashed patch 2/2
- zapped the TFA9879_REG macro
- zapped tfa9879_probe (which needlessly registered the regmap)
- moved tfa9879_prepare/_shutdown to a DAPM_SUPPLY widget
- zapped the tfa9879_volatile() thing
- made tfa9879_dai_ops const
- erased the redundant "Gain" from the bass/treble volume controls
- using params_width() instead of params_format()

Cheers,
Peter


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/