mbox series

[v2,00/11] ASoC: Add support to WCD9340/WCD9341 codec

Message ID 20191018001849.27205-1-srinivas.kandagatla@linaro.org
Headers show
Series ASoC: Add support to WCD9340/WCD9341 codec | expand

Message

Srinivas Kandagatla Oct. 18, 2019, 12:18 a.m. UTC
This patchset adds support to Qualcomm WCD9340/WCD9341 Codec which
is a standalone Hi-Fi audio codec IC.
This codec supports both I2S/I2C and SLIMbus audio interfaces.
On slimbus interface it supports two data lanes; 16 Tx ports
and 8 Rx ports. It has Five DACs and seven dedicated interpolators,
Multibutton headset control (MBHC), Active noise cancellation,
Sidetone paths, MAD (mic activity detection) and codec processing engine.
It supports Class-H differential earpiece out and stereo single
ended headphones out.

This codec also has integrated SoundWire controller.
Patchset for this is already sent for review at
https://patchwork.kernel.org/cover/11185769/
    
This patchset has been tested on SDM845 based DragonBoard DB845c and
Lenovo Yoga C630 laptop with WSA881x smart speaker amplifiers via
soundwire and 4 DMICs.

Pin Controller patch does not have any link dependency, it can go by its own.

Most of the code in this driver is rework of Qualcomm downstream drivers
used in Andriod. Credits to Banajit Goswami and Patrick Lai's Team.

If anyone is interested to try, here are working set of patches on top of rc3.
https://git.linaro.org/people/srinivas.kandagatla/linux.git/log/?h=audio/v5.4-rc3-YOGA-C630
alsa ucm files:
https://git.linaro.org/people/srinivas.kandagatla/alsa-lib.git/log/?h=DB845c

Thanks,
srini

Changes since v1:
- Code cleanup and convert to proper dpcm widgets where possible.
- converted to mfd driver.
- added pinctrl driver to this series
- added dts changes in this series
- bindings converted to yaml.

Srinivas Kandagatla (10):
  ASoC: dt-bindings: add dt bindings for WCD9340/WCD9341 audio codec
  mfd: wcd934x: add support to wcd9340/wcd9341 codec
  ASoC: wcd934x: add support to wcd9340/wcd9341 codec
  ASoC: wcd934x: add basic controls
  ASoC: wcd934x: add playback dapm widgets
  ASoC: wcd934x: add capture dapm widgets
  ASoC: wcd934x: add audio routings
  dt-bindings: pinctrl: qcom-wcd934x: Add bindings for gpio
  ASoC: dt-bindings: Add compatible for DB845c and Lenovo Yoga
  ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga

Yeleswarapu Nagaradhesh (1):
  pinctrl: qcom-wcd934x: Add support to wcd934x pinctrl driver.

 .../pinctrl/qcom,wcd934x-pinctrl.yaml         |   51 +
 .../devicetree/bindings/sound/qcom,sdm845.txt |    5 +-
 .../bindings/sound/qcom,wcd934x.yaml          |  169 +
 drivers/mfd/Kconfig                           |    8 +
 drivers/mfd/Makefile                          |    1 +
 drivers/mfd/wcd934x.c                         |  330 ++
 drivers/pinctrl/qcom/Kconfig                  |    7 +
 drivers/pinctrl/qcom/Makefile                 |    1 +
 drivers/pinctrl/qcom/pinctrl-wcd934x-gpio.c   |  365 ++
 include/linux/mfd/wcd934x/registers.h         |  529 ++
 include/linux/mfd/wcd934x/wcd934x.h           |   24 +
 sound/soc/codecs/Kconfig                      |   10 +
 sound/soc/codecs/Makefile                     |    2 +
 sound/soc/codecs/wcd934x.c                    | 5218 +++++++++++++++++
 sound/soc/qcom/sdm845.c                       |   71 +-
 15 files changed, 6789 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,wcd934x-pinctrl.yaml
 create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml
 create mode 100644 drivers/mfd/wcd934x.c
 create mode 100644 drivers/pinctrl/qcom/pinctrl-wcd934x-gpio.c
 create mode 100644 include/linux/mfd/wcd934x/registers.h
 create mode 100644 include/linux/mfd/wcd934x/wcd934x.h
 create mode 100644 sound/soc/codecs/wcd934x.c

-- 
2.21.0

Comments

Lee Jones Oct. 21, 2019, 1:19 p.m. UTC | #1
On Mon, 21 Oct 2019, Srinivas Kandagatla wrote:

> 

> 

> On 21/10/2019 12:45, Lee Jones wrote:

> > On Mon, 21 Oct 2019, Srinivas Kandagatla wrote:

> > 

> > > Thanks Lee for taking time to review.

> > > 

> > > I agree with most of the style related comments, will fix them in next

> > > version. For others I have replied it inline.

> > 

> > [...]

> > 

> > > > > +static int wcd934x_slim_status(struct slim_device *sdev,

> > > > > +			       enum slim_device_status status)

> > > > > +{

> > > > > +	struct device *dev = &sdev->dev;

> > > > > +	struct wcd934x_data *wcd;

> > > > > +	int ret;

> > > > 

> > > > This is semantically odd!  Why are you doing most of the

> > > > initialisation and bring-up in 'status' and not 'probe'.  Seems

> > > > broken to me.

> > > 

> > > SLIMBus device will not be in a state to communicate before enumeration (at

> > > probe), so all the device initialization is done in status callback where it

> > > is ready for communication.

> > 

> > Why do we need the device to be up *before* calling probe?

> > 

> 

> To Initialize the device.

> And SLIMbus device registers access can not be done before enumeration.


I'm not sure why you need any hardware to be enabled before calling
.probe(). That is the purpose of .probe(). The only way in which I can
see this being a requirement is if information located on the device
is required in order to do device-driver matching.

In which case, how was the .status() function matched?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Rob Herring (Arm) Oct. 25, 2019, 9 p.m. UTC | #2
On Fri, Oct 18, 2019 at 01:18:46AM +0100, Srinivas Kandagatla wrote:
> Qualcomm Technologies Inc WCD9340/WCD9341 Audio Codec has integrated

> gpio controller to control 5 gpios on the chip. This patch adds

> required device tree bindings for it.

> 

> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>

> ---

>  .../pinctrl/qcom,wcd934x-pinctrl.yaml         | 51 +++++++++++++++++++

>  1 file changed, 51 insertions(+)

>  create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,wcd934x-pinctrl.yaml

> 

> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,wcd934x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,wcd934x-pinctrl.yaml

> new file mode 100644

> index 000000000000..c8a36cbc4935

> --- /dev/null

> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,wcd934x-pinctrl.yaml

> @@ -0,0 +1,51 @@

> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)

> +%YAML 1.2

> +---

> +$id: http://devicetree.org/schemas/pinctrl/qcom,wcd934x-pinctrl.yaml#

> +$schema: http://devicetree.org/meta-schemas/core.yaml#

> +

> +title: WCD9340/WCD9341 GPIO Pin controller

> +

> +maintainers:

> +  - Srinivas Kandagatla <srinivas.kandagatla@linaro.org>

> +

> +description: |

> +  Qualcomm Technologies Inc WCD9340/WCD9341 Audio Codec has integrated

> +  gpio controller to control 5 gpios on the chip.

> +

> +properties:

> +  compatible:

> +    enum:

> +      - qcom,wcd9340-pinctrl

> +      - qcom,wcd9341-pinctrl

> +

> +  reg:

> +    maxItems: 1

> +

> +  gpio-controller: true

> +

> +  gpio-ranges:

> +    maxItems: 1

> +

> +  '#gpio-cells':

> +    const: 2

> +

> +required:

> +  - compatible

> +  - reg

> +  - gpio-controller

> +  - gpio-ranges

> +  - "#gpio-cells"


additionalProperties: false

> +

> +

> +examples:

> +  - |

> +    wcdpinctrl: wcdpinctrl@42 {


pinctrl@42

> +        compatible = "qcom,wcd9340-pinctrl";

> +        reg = <0x042 0x2>;

> +        gpio-controller;

> +        gpio-ranges = <&wcdpinctrl 0 0 5>;

> +        #gpio-cells = <2>;

> +    };

> +

> +...

> -- 

> 2.21.0

>
Srinivas Kandagatla Oct. 30, 2019, 9:55 a.m. UTC | #3
On 29/10/2019 20:47, Rob Herring wrote:
> On Mon, Oct 28, 2019 at 7:45 AM Srinivas Kandagatla

> <srinivas.kandagatla@linaro.org> wrote:

>>

>>

>>

>> On 28/10/2019 12:40, Srinivas Kandagatla wrote:

>>> Its Phandle.

>>>

>>> something like this is okay?

>>>

>>> slim-ifc-dev:

>>>     $ref: '/schemas/types.yaml#/definitions/phandle-array'

>>

>> Sorry this should not be an array, so something like this:

>>

>>     slim-ifc-dev:

>>       description: SLIMBus Interface device phandle

> 

> You're just spelling out the abbreviated name. I can do that much.

> What is 'SLIMBus Interface device'?


Each SLIMBus Component contains one Interface Device. Which is 
responsible for Monitoring and reporting the status of component, Data 
line to Data pin connection setup for SLIMBus streaming. Interface 
device is enumerated just like any other slim device.

We already have exactly same bindings for WCD9335 in upstream at:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt?h=v5.4-rc5#n42

> 

> Is it a standard SLIMBus property? If so, document it in the right

> place. If not, then needs a vendor prefix.


"SLIMBus Interface Device" itself is documented in SLIMBus Specification.

If I remember it correctly You suggested me to move to "slim-ifc-dev" 
as this is part of SLIMBus Specification.

Thanks,
srini


> 

>>       $ref: '/schemas/types.yaml#/definitions/phandle'

>>

>>

>>>     description: SLIMBus Interface device phandle
Rob Herring (Arm) Nov. 5, 2019, 7:08 p.m. UTC | #4
On Wed, Oct 30, 2019 at 4:55 AM Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>

>

>

> On 29/10/2019 20:47, Rob Herring wrote:

> > On Mon, Oct 28, 2019 at 7:45 AM Srinivas Kandagatla

> > <srinivas.kandagatla@linaro.org> wrote:

> >>

> >>

> >>

> >> On 28/10/2019 12:40, Srinivas Kandagatla wrote:

> >>> Its Phandle.

> >>>

> >>> something like this is okay?

> >>>

> >>> slim-ifc-dev:

> >>>     $ref: '/schemas/types.yaml#/definitions/phandle-array'

> >>

> >> Sorry this should not be an array, so something like this:

> >>

> >>     slim-ifc-dev:

> >>       description: SLIMBus Interface device phandle

> >

> > You're just spelling out the abbreviated name. I can do that much.

> > What is 'SLIMBus Interface device'?

>

> Each SLIMBus Component contains one Interface Device. Which is

> responsible for Monitoring and reporting the status of component, Data

> line to Data pin connection setup for SLIMBus streaming. Interface

> device is enumerated just like any other slim device.


So a standard set of registers every slimbus device has? In hindsight,
I would have made reg have 2 entries with both addresses. I guess that
ship has sailed.

It seems strange you would need both "devices" described as separate
nodes in DT.

>

> We already have exactly same bindings for WCD9335 in upstream at:

>

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt?h=v5.4-rc5#n42

>

> >

> > Is it a standard SLIMBus property? If so, document it in the right

> > place. If not, then needs a vendor prefix.

>

> "SLIMBus Interface Device" itself is documented in SLIMBus Specification.

>

> If I remember it correctly You suggested me to move to "slim-ifc-dev"

> as this is part of SLIMBus Specification.


Probably so. If it is common, then document it in bindings/slimbus/bus.txt.

Then here, 'slim-ifc-dev: true' is sufficient. You can just assume we
convert bus.txt to schema (or feel free to do that :) ).

Rob
Rob Herring (Arm) Nov. 6, 2019, 7:20 p.m. UTC | #5
On Wed, Nov 6, 2019 at 12:09 PM Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>

>

>

> On 05/11/2019 19:08, Rob Herring wrote:

> > On Wed, Oct 30, 2019 at 4:55 AM Srinivas Kandagatla

> > <srinivas.kandagatla@linaro.org> wrote:

> >>

> >>

> >>

> >> On 29/10/2019 20:47, Rob Herring wrote:

> >>> On Mon, Oct 28, 2019 at 7:45 AM Srinivas Kandagatla

> >>> <srinivas.kandagatla@linaro.org> wrote:

> >>>>

> >>>>

> >>>>

> >>>> On 28/10/2019 12:40, Srinivas Kandagatla wrote:

> >>>>> Its Phandle.

> >>>>>

> >>>>> something like this is okay?

> >>>>>

> >>>>> slim-ifc-dev:

> >>>>>      $ref: '/schemas/types.yaml#/definitions/phandle-array'

> >>>>

> >>>> Sorry this should not be an array, so something like this:

> >>>>

> >>>>      slim-ifc-dev:

> >>>>        description: SLIMBus Interface device phandle

> >>>

> >>> You're just spelling out the abbreviated name. I can do that much.

> >>> What is 'SLIMBus Interface device'?

> >>

> >> Each SLIMBus Component contains one Interface Device. Which is

> >> responsible for Monitoring and reporting the status of component, Data

> >> line to Data pin connection setup for SLIMBus streaming. Interface

> >> device is enumerated just like any other slim device.

> >

> > So a standard set of registers every slimbus device has? In hindsight,

> > I would have made reg have 2 entries with both addresses. I guess that

> > ship has sailed.

>

> That will break SLIMBus bindings, Which is expecting one device per

> device node.


Like I said, that ship has sailed...

> >

> > It seems strange you would need both "devices" described as separate

> > nodes in DT.

>

> Because they are two different devices on the SLIMBus Component.

>

> >

> >>

> >> We already have exactly same bindings for WCD9335 in upstream at:

> >>

> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/qcom,wcd9335.txt?h=v5.4-rc5#n42

> >>

> >>>

> >>> Is it a standard SLIMBus property? If so, document it in the right

> >>> place. If not, then needs a vendor prefix.

> >>

> >> "SLIMBus Interface Device" itself is documented in SLIMBus Specification.

> >>

> >> If I remember it correctly You suggested me to move to "slim-ifc-dev"

> >> as this is part of SLIMBus Specification.

> >

> > Probably so. If it is common, then document it in bindings/slimbus/bus.txt.

> >

> As we are dealing with audio codecs here, it might be that

> "slim-ifc-dev" is common across wcd9335 and wcd934x but not all devices

> on the SLIMBus Component would need handle to interface device. SLIMbus

> can also be used for control buses as well which might not need this.


Like you said, it's part of the the spec, so define it somewhere
common, not in a device specific binding.

> > Then here, 'slim-ifc-dev: true' is sufficient. You can just assume we

> > convert bus.txt to schema (or feel free to do that :) ).

>

> We need phandle to the interface device so that we can program the

> streaming parameters for the SLIMBus Component.


'true' just means 'I'm using the property' and have no other
constraints. The constraints like type would be defined in the common
binding and no need to duplicate here.

Rob