path: root/sound/soc/soc-ac97.c
AgeCommit message (Collapse)AuthorFilesLines
2016-04-26ASoC: ac97: use gpiochip data pointerLinus Walleij1-5/+3
This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: Liam Girdwood <> Cc: Acked-by: Mark Brown <> Signed-off-by: Linus Walleij <>
2016-01-17Merge tag 'gpio-v4.5-1' of ↵Linus Torvalds1-1/+1
git:// Pull GPIO updates from Linus Walleij: "Here is the bulk of GPIO changes for v4.5. Notably there are big refactorings mostly by myself, aimed at getting the gpio_chip into a shape that makes me believe I can proceed to preserve state for a proper userspace ABI (character device) that has already been proposed once, but resulted in the feedback that I need to go back and restructure stuff. So I've been restructuring stuff. On the way I ran into brokenness (return code from the get_value() callback) and had to fix it. Also, refactored generic GPIO to be simpler. Some of that is still waiting to trickle down from the subsystems all over the kernel that provide random gpio_chips, I've touched every single GPIO driver in the kernel now, oh man I didn't know I was responsible for so much... Apart from that we're churning along as usual. I took some effort to test and retest so it should merge nicely and we shook out a couple of bugs in -next. Infrastructural changes: - In struct gpio_chip, rename the .dev node to .parent to better reflect the fact that this is not the GPIO struct device abstraction. We will add that soon so this would be totallt confusing. - It was noted that the driver .get_value() callbacks was sometimes reporting negative -ERR values to the gpiolib core, expecting them to be propagated to consumer gpiod_get_value() and gpio_get_value() calls. This was not happening, so as there was a mess of drivers returning negative errors and some returning "anything else than zero" to indicate that a line was active. As some would have bit 31 set to indicate "line active" it clashed with negative error codes. This is fixed by the largeish series clamping values in all drivers with !!value to [0,1] and then augmenting the code to propagate error codes to consumers. (Includes some ACKed patches in other subsystems.) - Add a void *data pointer to struct gpio_chip. The container_of() design pattern is indeed very nice, but we want to reform the struct gpio_chip to be a non-volative, stateless business, and keep states internal to the gpiolib to be able to hold on to the state when adding a proper userspace ABI (character device) further down the road. To achieve this, drivers need a handle at the internal state that is not dependent on their struct gpio_chip() so we add gpiochip_add_data() and gpiochip_get_data() following the pattern of many other subsystems. All the "use gpiochip data pointer" patches transforms drivers to this scheme. - The Generic GPIO chip header has been merged into the general <linux/gpio/driver.h> header, and the custom header for that removed. Instead of having a separate mm_gpio_chip struct for these generic drivers, merge that into struct gpio_chip, simplifying the code and removing the need for separate and confusing includes. Misc improvements: - Stabilize the way GPIOs are looked up from the ACPI legacy specification. - Incremental driver features for PXA, PCA953X, Lantiq (patches from the OpenWRT community), RCAR, Zynq, PL061, 104-idi-48 New drivers: - Add a GPIO chip to the ALSA SoC AC97 driver. - Add a new Broadcom NSP SoC driver (this lands in the pinctrl dir, but the branch is merged here too to account for infrastructural changes). - The sx150x driver now supports the sx1502" * tag 'gpio-v4.5-1' of git:// (220 commits) gpio: generic: make bgpio_pdata always visible gpiolib: fix chip order in gpio list gpio: mpc8xxx: Do not use gpiochip_get_data() in mpc8xxx_gpio_save_regs() gpio: mm-lantiq: Do not use gpiochip_get_data() in ltq_mm_save_regs() gpio: brcmstb: Allow building driver for BMIPS_GENERIC gpio: brcmstb: Set endian flags for big-endian MIPS gpio: moxart: fix build regression gpio: xilinx: Do not use gpiochip_get_data() in xgpio_save_regs() leds: pca9532: use gpiochip data pointer leds: tca6507: use gpiochip data pointer hid: cp2112: use gpiochip data pointer bcma: gpio: use gpiochip data pointer avr32: gpio: use gpiochip data pointer video: fbdev: via: use gpiochip data pointer gpio: pch: Optimize pch_gpio_get() Revert "pinctrl: lantiq: Implement gpio_chip.to_irq" pinctrl: nsp-gpio: use gpiochip data pointer pinctrl: vt8500-wmt: use gpiochip data pointer pinctrl: exynos5440: use gpiochip data pointer pinctrl: at91-pio4: use gpiochip data pointer ...
2015-12-23ASoC: ac97: Be sure to clamp return valueLinus Walleij1-1/+1
As we want gpio_chip .get() calls to be able to return negative error codes and propagate to drivers, we need to go over all drivers and make sure their return values are clamped to [0,1]. We do this by using the ret = !!(val) design pattern. Signed-off-by: Linus Walleij <> Signed-off-by: Mark Brown <>
2015-12-07ASoC: ac97: fix parent assignmentLinus Walleij1-1/+1
Upstream GPIO has substituted .dev for .parent in struct gpio_chip. Signed-off-by: Linus Walleij <>
2015-11-18ASoC: ac97: add gpio chipRobert Jarzmik1-0/+125
The AC97 specification provides a guide for 16 GPIOs in the codecs. If the gpiolib is compiled in the kernel, declare a gpio chip. This was tested with a pxa27x board (mioa701) and a wm9713 codec. Signed-off-by: Robert Jarzmik <> Signed-off-by: Mark Brown <>
2015-07-23ASoC: ac97: Add support for resetting device before registrationLars-Peter Clausen1-5/+25
AC97 devices need to be initially reset before they can be used. Currently each driver does this on its own. Add support for resetting the device to core in snd_soc_new_ac97_codec(). If the caller supplies a device ID and device ID mask the function will reset the device and verify that it has the correct ID, if it does not a error is returned. This will allow to remove custom code with similar functionality from individual drivers. Signed-off-by: Lars-Peter Clausen <> Reviewed-by: Takashi Iwai <> Signed-off-by: Mark Brown <>
2015-01-26ASoC: Add support for allocating AC'97 device before registering itLars-Peter Clausen1-6/+30
In some cases it is necessary to before additional operations after the device has been initialized and before the device is registered. This can for example be resetting the device. This patch introduces a new function snd_soc_alloc_ac97_codec() which is similar to snd_soc_new_ac97_codec() except that it does not register the device. Any users of snd_soc_alloc_ac97_codec() are responsible for calling device_add() manually. Fixes: 6794f709b712 ("ASoC: ac97: Drop delayed device registration") Reported-by: Manuel Lauss <> Signed-off-by: Lars-Peter Clausen <> Tested-by: Manuel Lauss <> Signed-off-by: Mark Brown <> Cc:
2014-11-18ASoC: ac97: Push snd_ac97 pointer to the driver levelLars-Peter Clausen1-19/+21
Now that the ASoC core no longer needs a handle to the AC'97 device that is associated with a CODEC we can remove it from the snd_soc_codec struct and push it into the individual driver state structs like we do for other communication buses. Doing so creates a clean separation between the AC'97 bus support and the ASoC core. Signed-off-by: Lars-Peter Clausen <> Acked-by: Charles Keepax <> Signed-off-by: Mark Brown <>
2014-11-18ASoC: ac97: Drop delayed device registrationLars-Peter Clausen1-104/+14
We have all the information and dependencies we need to initialize and register the device available in snd_soc_new_ac97_codec(). So there is no need to delay the device registration until after the card itself as been registered. This makes the code significantly simpler and also makes it possible to use the AC'97 device in the CODECs probe function. The later will be required to be able to convert the AC'97 CODEC drivers to regmap. Signed-off-by: Lars-Peter Clausen <> Signed-off-by: Mark Brown <>
2014-11-18ASoC: ac97: Drop support for setting platform data via the CPU DAILars-Peter Clausen1-12/+0
This has no users since commit f0fba2ad1b6b ("ASoC: multi-component - ASoC Multi-Component Support") which was almost 5 years ago. Given that this runs after CODEC probe functions have been run it also doesn't seem to be that useful. So drop it altogether to make the code simpler. Signed-off-by: Lars-Peter Clausen <> Signed-off-by: Mark Brown <>
2014-11-18ASoC: ac97: Merge soc_ac97_dev_{un,}register()/soc_{un,}register_ac97_codec()Lars-Peter Clausen1-50/+30
soc_{un,}register_ac97_codec() is just a simple wrapper around soc_ac97_dev_{un,}register(). There is no need to split these up into two different sets of functions. Signed-off-by: Lars-Peter Clausen <> Signed-off-by: Mark Brown <>
2014-11-18ASoC: ac97: Use static ac97_busLars-Peter Clausen1-14/+8
We always pass soc_ac97_ops to snd_soc_new_ac97_codec(). So instead of allocating a snd_ac97_bus in snd_soc_new_ac97_codec() just use a static one that gets initialized when snd_soc_set_ac97_ops() is called. Also drop the device number parameter from snd_soc_new_ac97_codec(). We currently only support one device per bus and all drivers pass 0 for the device number. And if we should ever support multiple devices per bus it wouldn't be up to individual AC'97 device drivers to pick their number, but rather either the AC'97 adapter driver or the core code will assign them. Signed-off-by: Lars-Peter Clausen <> Acked-by: Charles Keepax <> Signed-off-by: Mark Brown <>
2014-11-18ASoC: Move AC'97 support to its own fileLars-Peter Clausen1-0/+382
Currently the AC'97 support is splattered all throughout soc-core.c. Some parts are #ifdef'd some parts are not. This patch moves the AC'97 support to its own file, this should make the code a bit more clearer and also makes it possible to easily not compile it into the kernel when not needed. Signed-off-by: Lars-Peter Clausen <> Signed-off-by: Mark Brown <>