diff mbox

sound/tlv320dac33: Add device tree support

Message ID 20180129230539.GA18280@amd (mailing list archive)
State New, archived
Headers show

Commit Message

Pavel Machek Jan. 29, 2018, 11:05 p.m. UTC
This adds device tree support to tlv320dac33.c.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

Comments

Ladislav Michl Jan. 29, 2018, 11:20 p.m. UTC | #1
On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> 
> This adds device tree support to tlv320dac33.c.
> 
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> new file mode 100644
> index 0000000..6cbd311
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> @@ -0,0 +1,32 @@
> +Texas Instruments - tlv320dac33 Codec module
> +
> +The tlv320dac33 serial control bus communicates through I2C protocols.
> +
> +Required properties:
> +
> +- compatible - "ti,tlv320dac33"
> +- reg - I2C slave address
> +
> +Optional properties:
> +
> +- power-gpios - gpio pin to power the device, active high

While driver used gpio in platform data, isn't it more likely
regulator which powers device?

> +- interrupts       - The interrupt output from the device.
> +- interrupt-parent - The parent interrupt controller.
> +
> +- ti,keep-bclk 	- Keep the BCLK running in FIFO modes
> +- ti,burst-bclkdiv - BCLK divider value in burst mode
> +
> +Example:
> +
> +tlv320dac33: audio-codec@19 {
> +	compatible = "ti,tlv320dac33";
> +	reg = <0x19>;
> +
> +	interrupt-parent = <&gpio2>;
> +	interrupts = <21 1>; /* gpio_53, IRQF_TRIGGER_RISING */
> +	power-gpio = <&gpio2 28 0>; /* gpio_60 */
> +
> +	ti,keep-bclk;
> +	ti,burst-bclkdiv = <3>;
> +};
> diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
> index 5b94a15..2a0fe06 100644
> --- a/sound/soc/codecs/tlv320dac33.c
> +++ b/sound/soc/codecs/tlv320dac33.c
> @@ -30,6 +32,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/gpio.h>
>  #include <linux/regulator/consumer.h>
> +#include <linux/of_gpio.h>
>  #include <linux/slab.h>
>  #include <sound/core.h>
>  #include <sound/pcm.h>
> @@ -105,7 +108,7 @@ struct tlv320dac33_priv {
>  	unsigned int nsample;		/* burst read amount from host */
>  	int mode1_latency;		/* latency caused by the i2c writes in
>  					 * us */
> -	u8 burst_bclkdiv;		/* BCLK divider value in burst mode */
> +	u32 burst_bclkdiv;		/* BCLK divider value in burst mode */
>  	unsigned int burst_rate;	/* Interface speed in Burst modes */
>  
>  	int keep_bclk;			/* Keep the BCLK continuously running
> @@ -1484,16 +1487,11 @@ static struct snd_soc_dai_driver dac33_dai = {
>  static int dac33_i2c_probe(struct i2c_client *client,
>  			   const struct i2c_device_id *id)
>  {
> -	struct tlv320dac33_platform_data *pdata;
> +	struct tlv320dac33_platform_data *pdata = client->dev.platform_data;
>  	struct tlv320dac33_priv *dac33;
> +	struct device_node *np = client->dev.of_node;
>  	int ret, i;
>  
> -	if (client->dev.platform_data == NULL) {
> -		dev_err(&client->dev, "Platform data not set\n");
> -		return -ENODEV;
> -	}
> -	pdata = client->dev.platform_data;
> -
>  	dac33 = devm_kzalloc(&client->dev, sizeof(struct tlv320dac33_priv),
>  			     GFP_KERNEL);
>  	if (dac33 == NULL)
> @@ -1505,10 +1503,26 @@ static int dac33_i2c_probe(struct i2c_client *client,
>  
>  	i2c_set_clientdata(client, dac33);
>  
> -	dac33->power_gpio = pdata->power_gpio;
> -	dac33->burst_bclkdiv = pdata->burst_bclkdiv;
> -	dac33->keep_bclk = pdata->keep_bclk;
> -	dac33->mode1_latency = pdata->mode1_latency;
> +	if (pdata) {
> +		dac33->power_gpio = pdata->power_gpio;
> +		dac33->burst_bclkdiv = pdata->burst_bclkdiv;
> +		dac33->keep_bclk = pdata->keep_bclk;
> +		dac33->mode1_latency = pdata->mode1_latency;
> +	} else if (np) {
> +		ret = of_get_named_gpio(np, "power-gpios", 0);
> +		if (ret >= 0)
> +			dac33->power_gpio = ret;
> +		else
> +			dac33->power_gpio = -1;
> +
> +		if (of_property_read_bool(np, "ti,keep-bclk"))
> +			dac33->keep_bclk = true;
> +
> +		of_property_read_u32(np, "ti,burst-bclkdiv", &dac33->burst_bclkdiv);
> +	} else {
> +		dev_err(&client->dev, "Platform data not set\n");
> +		return -ENODEV;
> +	}
>  	if (!dac33->mode1_latency)
>  		dac33->mode1_latency = 10000; /* 10ms */
>  	dac33->irq = client->irq;
> @@ -1574,9 +1588,16 @@ static const struct i2c_device_id tlv320dac33_i2c_id[] = {
>  };
>  MODULE_DEVICE_TABLE(i2c, tlv320dac33_i2c_id);
>  
> +static const struct of_device_id tlv320dac33_of_match[] = {
> +	{ .compatible = "ti,tlv320dac33", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(i2c, tlv320dac33_of_match);
> +
>  static struct i2c_driver tlv320dac33_i2c_driver = {
>  	.driver = {
>  		.name = "tlv320dac33-codec",
> +		.of_match_table = of_match_ptr(tlv320dac33_of_match),
>  	},
>  	.probe		= dac33_i2c_probe,
>  	.remove		= dac33_i2c_remove,
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek Jan. 29, 2018, 11:33 p.m. UTC | #2
On Tue 2018-01-30 00:20:31, Ladislav Michl wrote:
> On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> > 
> > This adds device tree support to tlv320dac33.c.
> > 
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > 
> > diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > new file mode 100644
> > index 0000000..6cbd311
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > @@ -0,0 +1,32 @@
> > +Texas Instruments - tlv320dac33 Codec module
> > +
> > +The tlv320dac33 serial control bus communicates through I2C protocols.
> > +
> > +Required properties:
> > +
> > +- compatible - "ti,tlv320dac33"
> > +- reg - I2C slave address
> > +
> > +Optional properties:
> > +
> > +- power-gpios - gpio pin to power the device, active high
> 
> While driver used gpio in platform data, isn't it more likely
> regulator which powers device?

                power-gpios = <&gpio2 28 0>; /* gpio_60 */

Looks like GPIO to me -- example is from Nokia N9. So this appears to
be correct.

								Pavel
Ladislav Michl Jan. 30, 2018, 8:34 a.m. UTC | #3
On Tue, Jan 30, 2018 at 12:33:01AM +0100, Pavel Machek wrote:
> On Tue 2018-01-30 00:20:31, Ladislav Michl wrote:
> > On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> > > 
> > > This adds device tree support to tlv320dac33.c.
> > > 
> > > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > > 
> > > diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > > new file mode 100644
> > > index 0000000..6cbd311
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > > @@ -0,0 +1,32 @@
> > > +Texas Instruments - tlv320dac33 Codec module
> > > +
> > > +The tlv320dac33 serial control bus communicates through I2C protocols.
> > > +
> > > +Required properties:
> > > +
> > > +- compatible - "ti,tlv320dac33"
> > > +- reg - I2C slave address
> > > +
> > > +Optional properties:
> > > +
> > > +- power-gpios - gpio pin to power the device, active high
> > 
> > While driver used gpio in platform data, isn't it more likely
> > regulator which powers device?
> 
>                 power-gpios = <&gpio2 28 0>; /* gpio_60 */
> 
> Looks like GPIO to me -- example is from Nokia N9. So this appears to
> be correct.

Device datasheet doesn't list any pin which looks like "power-gpio"
http://www.ti.com/lit/ds/symlink/tlv320dac32.pdf
Unfortunately I do not know much about N9, but was able to find Nokia 5610
scheme to get clue how could be tlv320dac33 hardwired (see page 2):
http://mastermobile.spb.ru/service/nokia_5610_rm-242_service_schematics.pdf
Here AVDD is powered by LP3985 voltage regulator which is enabled using
VEN pin which might be connected to gpio. Or there could be completely
different voltage regulator with different controls. And since Linux
already has voltage regulator class, lets not limit ourselves to gpio
pins.

See also here about deprecated power-gpios:
Documentation/devicetree/bindings/mmc/cavium-mmc.txt
so it seems others already fallen into that trap.

	ladis
Pavel Machek Jan. 30, 2018, 8:53 a.m. UTC | #4
On Tue 2018-01-30 09:34:46, Ladislav Michl wrote:
> On Tue, Jan 30, 2018 at 12:33:01AM +0100, Pavel Machek wrote:
> > On Tue 2018-01-30 00:20:31, Ladislav Michl wrote:
> > > On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> > > > 
> > > > This adds device tree support to tlv320dac33.c.
> > > > 
> > > > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > > > new file mode 100644
> > > > index 0000000..6cbd311
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > > > @@ -0,0 +1,32 @@
> > > > +Texas Instruments - tlv320dac33 Codec module
> > > > +
> > > > +The tlv320dac33 serial control bus communicates through I2C protocols.
> > > > +
> > > > +Required properties:
> > > > +
> > > > +- compatible - "ti,tlv320dac33"
> > > > +- reg - I2C slave address
> > > > +
> > > > +Optional properties:
> > > > +
> > > > +- power-gpios - gpio pin to power the device, active high
> > > 
> > > While driver used gpio in platform data, isn't it more likely
> > > regulator which powers device?
> > 
> >                 power-gpios = <&gpio2 28 0>; /* gpio_60 */
> > 
> > Looks like GPIO to me -- example is from Nokia N9. So this appears to
> > be correct.
> 
> Device datasheet doesn't list any pin which looks like "power-gpio"
> http://www.ti.com/lit/ds/symlink/tlv320dac32.pdf
> Unfortunately I do not know much about N9, but was able to find Nokia 5610
> scheme to get clue how could be tlv320dac33 hardwired (see page 2):
> http://mastermobile.spb.ru/service/nokia_5610_rm-242_service_schematics.pdf
> Here AVDD is powered by LP3985 voltage regulator which is enabled using
> VEN pin which might be connected to gpio. Or there could be completely
> different voltage regulator with different controls. And since Linux
> already has voltage regulator class, lets not limit ourselves to gpio
> pins.

Well, notice I'm converting existing driver to device tree. And that
one already has GPIO dependency. It is possible that more work needs
to be done there, but that should not be a reason to delay this. Feel
free to help.

									Pavel
Ladislav Michl Jan. 30, 2018, 9:38 a.m. UTC | #5
On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> Hi,
> 
> On 01/30/2018 09:53 AM, Pavel Machek wrote:
> > On Tue 2018-01-30 09:34:46, Ladislav Michl wrote:
> >> On Tue, Jan 30, 2018 at 12:33:01AM +0100, Pavel Machek wrote:
> >>> On Tue 2018-01-30 00:20:31, Ladislav Michl wrote:
> >>>> On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> >>>>>
> >>>>> This adds device tree support to tlv320dac33.c.
> >>>>>
> >>>>> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> >>>>> new file mode 100644
> >>>>> index 0000000..6cbd311
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> >>>>> @@ -0,0 +1,32 @@
> >>>>> +Texas Instruments - tlv320dac33 Codec module
> >>>>> +
> >>>>> +The tlv320dac33 serial control bus communicates through I2C protocols.
> >>>>> +
> >>>>> +Required properties:
> >>>>> +
> >>>>> +- compatible - "ti,tlv320dac33"
> >>>>> +- reg - I2C slave address
> >>>>> +
> >>>>> +Optional properties:
> >>>>> +
> >>>>> +- power-gpios - gpio pin to power the device, active high
> >>>>
> >>>> While driver used gpio in platform data, isn't it more likely
> >>>> regulator which powers device?
> >>>
> >>>                 power-gpios = <&gpio2 28 0>; /* gpio_60 */
> >>>
> >>> Looks like GPIO to me -- example is from Nokia N9. So this appears to
> >>> be correct.
> >>
> >> Device datasheet doesn't list any pin which looks like "power-gpio"
> >> http://www.ti.com/lit/ds/symlink/tlv320dac32.pdf
> >> Unfortunately I do not know much about N9, but was able to find Nokia 5610
> >> scheme to get clue how could be tlv320dac33 hardwired (see page 2):
> >> http://mastermobile.spb.ru/service/nokia_5610_rm-242_service_schematics.pdf
> >> Here AVDD is powered by LP3985 voltage regulator which is enabled using
> >> VEN pin which might be connected to gpio. Or there could be completely
> >> different voltage regulator with different controls. And since Linux
> >> already has voltage regulator class, lets not limit ourselves to gpio
> >> pins.
> > 
> > Well, notice I'm converting existing driver to device tree. And that
> > one already has GPIO dependency. It is possible that more work needs
> > to be done there, but that should not be a reason to delay this. Feel
> > free to help.

Adding DT properties that need to be maintained for compatibility reasons
is a bad idea and very good reason to delay merging unfinished stuff.
And meanwhile it turned out it is not power-gpio :)

> According to N9 schematics
> http://www.s-manuals.com/manuals/phone/nokia/nokia_n9_rm-696_service_schematics_v1.pdf
> it's in fact GPIO pin that is connected to reset line (labeled
> CODEC_RST). So calling it "power" might be misleading, but the driver
> code is quite clear as it labels that GPIO as "tlv320dac33 reset"

Thanks a lot! So now it is clear that gpio is connected to codec's nRESET pin,
therefore "reset-gpios" property seems reasonable here.

	ladis
Pavel Machek Jan. 30, 2018, 10 a.m. UTC | #6
On Tue 2018-01-30 10:38:38, Ladislav Michl wrote:
> On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> > Hi,
> > 

> > > Well, notice I'm converting existing driver to device tree. And that
> > > one already has GPIO dependency. It is possible that more work needs
> > > to be done there, but that should not be a reason to delay this. Feel
> > > free to help.
> 
> Adding DT properties that need to be maintained for compatibility reasons
> is a bad idea and very good reason to delay merging unfinished stuff.
> And meanwhile it turned out it is not power-gpio :)

I believe reset-gpios and power-gpios are commonly used like
this... and that's what the old code does.

You are not helping.

									Pavel
Ladislav Michl Jan. 30, 2018, 10:10 a.m. UTC | #7
On Tue, Jan 30, 2018 at 11:00:23AM +0100, Pavel Machek wrote:
> On Tue 2018-01-30 10:38:38, Ladislav Michl wrote:
> > On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> > > Hi,
> > > 
> 
> > > > Well, notice I'm converting existing driver to device tree. And that
> > > > one already has GPIO dependency. It is possible that more work needs
> > > > to be done there, but that should not be a reason to delay this. Feel
> > > > free to help.
> > 
> > Adding DT properties that need to be maintained for compatibility reasons
> > is a bad idea and very good reason to delay merging unfinished stuff.
> > And meanwhile it turned out it is not power-gpio :)
> 
> I believe reset-gpios and power-gpios are commonly used like
> this... and that's what the old code does.

Why do you care about old code when introducing new DT property?
Either it is reset, then lets call it reset-gpios or it is power supply
and then voltage regulator should be used (VAUX4.OUT is such a regulator
although it is unclear to me how it is controlled (*)).

> You are not helping.

The only way I can help here is to resend your patch with "reset-gpios"
used, which I'm pretty sure you can handle yourself.

(*) Remark "DAC33 enabled (for example, plug in a headset to the 3.5mm
AV connector and start music playback from the device)" in schematics
suggests it is controlled somehow.
Pavel Machek Jan. 30, 2018, 10:35 a.m. UTC | #8
On Tue 2018-01-30 11:10:46, Ladislav Michl wrote:
> On Tue, Jan 30, 2018 at 11:00:23AM +0100, Pavel Machek wrote:
> > On Tue 2018-01-30 10:38:38, Ladislav Michl wrote:
> > > On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> > > > Hi,
> > > > 
> > 
> > > > > Well, notice I'm converting existing driver to device tree. And that
> > > > > one already has GPIO dependency. It is possible that more work needs
> > > > > to be done there, but that should not be a reason to delay this. Feel
> > > > > free to help.
> > > 
> > > Adding DT properties that need to be maintained for compatibility reasons
> > > is a bad idea and very good reason to delay merging unfinished stuff.
> > > And meanwhile it turned out it is not power-gpio :)
> > 
> > I believe reset-gpios and power-gpios are commonly used like
> > this... and that's what the old code does.
> 
> Why do you care about old code when introducing new DT property?
> Either it is reset, then lets call it reset-gpios or it is power supply
> and then voltage regulator should be used (VAUX4.OUT is such a regulator
> although it is unclear to me how it is controlled (*)).

power gpio = !reset gpio. Difference is only in polarity.

> > You are not helping.
> 
> The only way I can help here is to resend your patch with "reset-gpios"
> used, which I'm pretty sure you can handle yourself.

Well, you can do that, and then you can argue with the next person who
feels one of the properties has to get his preferred color. Hard part
is not changing code :-(.

									Pavel

> (*) Remark "DAC33 enabled (for example, plug in a headset to the 3.5mm
> AV connector and start music playback from the device)" in schematics
> suggests it is controlled somehow.
Mark Brown Jan. 30, 2018, 11:32 a.m. UTC | #9
On Tue, Jan 30, 2018 at 09:53:14AM +0100, Pavel Machek wrote:

> Well, notice I'm converting existing driver to device tree. And that
> one already has GPIO dependency. It is possible that more work needs
> to be done there, but that should not be a reason to delay this. Feel
> free to help.

No, it's a very good reason to delay merging something.  A DT binding is
an ABI so we need to sort out interface issues and describe things as
well as we can, with board files it's not an ABI so we can just do any
old thing that happens to work and while it might not be ideal it
doesn't really matter since we can change it later if we need to.
Ladislav Michl Jan. 30, 2018, 11:38 a.m. UTC | #10
On Tue, Jan 30, 2018 at 11:35:38AM +0100, Pavel Machek wrote:
> On Tue 2018-01-30 11:10:46, Ladislav Michl wrote:
> > On Tue, Jan 30, 2018 at 11:00:23AM +0100, Pavel Machek wrote:
> > > On Tue 2018-01-30 10:38:38, Ladislav Michl wrote:
> > > > On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> > > > > Hi,
> > > > > 
> > > 
> > > > > > Well, notice I'm converting existing driver to device tree. And that
> > > > > > one already has GPIO dependency. It is possible that more work needs
> > > > > > to be done there, but that should not be a reason to delay this. Feel
> > > > > > free to help.
> > > > 
> > > > Adding DT properties that need to be maintained for compatibility reasons
> > > > is a bad idea and very good reason to delay merging unfinished stuff.
> > > > And meanwhile it turned out it is not power-gpio :)
> > > 
> > > I believe reset-gpios and power-gpios are commonly used like
> > > this... and that's what the old code does.
> > 
> > Why do you care about old code when introducing new DT property?
> > Either it is reset, then lets call it reset-gpios or it is power supply
> > and then voltage regulator should be used (VAUX4.OUT is such a regulator
> > although it is unclear to me how it is controlled (*)).
> 
> power gpio = !reset gpio. Difference is only in polarity.

Quick grep:
Documentation/devicetree/bindings/net/smsc-lan91c111.txt
- power-gpios: GPIO to control the PWRDWN pin
- reset-gpios: GPIO to control the RESET pin
Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
- ti,power-gpio :     GPIO connected to chip's PMEN pin
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
- power-gpios             : Specification for the pin connected to the gsl1680's
                            shutdown input. This needs to be driven high to take the
                            gsl1680 out of its low power state
Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
- power-gpios             : GPIO specification for the pin connected to the
                            ektf2127's wake input. This needs to be driven high
                            to take ektf2127 out of it's low power state

As you can see others are using it to drive pins different from nRESET. As
stated in datasheet:
"The TLV320DAC32 requires a hardware reset after power-up for proper operation.
After all power supplies are at their specified values, the nRESET pin must be
driven low for at least 10ns. If this reset sequence is not performed, the DAC32
may not respond properly to register reads/writes". That does not sound like
anything to do with power.

(It seems the only difference between TLV320DAC33 and TLV320DAC32 is uses a ball
grid array package vs QFN32)

> > > You are not helping.
> > 
> > The only way I can help here is to resend your patch with "reset-gpios"
> > used, which I'm pretty sure you can handle yourself.
> 
> Well, you can do that, and then you can argue with the next person who
> feels one of the properties has to get his preferred color. Hard part
> is not changing code :-(.

Indeed, hard part is not to break DT compatibility later. Consider someone
will have to add regulator support later, which you omitted to do - having
both power supply and power gpio is a bit confusing, don't you think?

Anyway, time to stop arguing, feel free to do what you think is right, I do
not have anything important to add :)

	ladis
Pavel Machek Jan. 30, 2018, 12:28 p.m. UTC | #11
On Tue 2018-01-30 11:32:38, Mark Brown wrote:
> On Tue, Jan 30, 2018 at 09:53:14AM +0100, Pavel Machek wrote:
> 
> > Well, notice I'm converting existing driver to device tree. And that
> > one already has GPIO dependency. It is possible that more work needs
> > to be done there, but that should not be a reason to delay this. Feel
> > free to help.
> 
> No, it's a very good reason to delay merging something.  A DT binding is
> an ABI so we need to sort out interface issues and describe things as
> well as we can, with board files it's not an ABI so we can just do any
> old thing that happens to work and while it might not be ideal it
> doesn't really matter since we can change it later if we need to.

Whatever.

Turns out this was GPIO after all.

I believe power-gpio and reset-gpio are equiavalent, with different
polarity. (After all, devices in reset consume less power).

If you prefer one solution over another, let me know...

									Pavel
Peter Ujfalusi Jan. 31, 2018, 9:12 a.m. UTC | #12
On 2018-01-30 01:20, Ladislav Michl wrote:
> On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
>>
>> This adds device tree support to tlv320dac33.c.
>>
>> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>>
>> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
>> new file mode 100644
>> index 0000000..6cbd311
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
>> @@ -0,0 +1,32 @@
>> +Texas Instruments - tlv320dac33 Codec module
>> +
>> +The tlv320dac33 serial control bus communicates through I2C protocols.
>> +
>> +Required properties:
>> +
>> +- compatible - "ti,tlv320dac33"
>> +- reg - I2C slave address
>> +
>> +Optional properties:
>> +
>> +- power-gpios - gpio pin to power the device, active high
> 
> While driver used gpio in platform data, isn't it more likely
> regulator which powers device?

It is GPIO, and according to the non public TRM it is connected to the
reset pin of the codec.

So the correct name should be reset-gpios

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Peter Ujfalusi Jan. 31, 2018, 9:24 a.m. UTC | #13
On 2018-01-30 13:38, Ladislav Michl wrote:
> On Tue, Jan 30, 2018 at 11:35:38AM +0100, Pavel Machek wrote:
>> On Tue 2018-01-30 11:10:46, Ladislav Michl wrote:
>>> On Tue, Jan 30, 2018 at 11:00:23AM +0100, Pavel Machek wrote:
>>>> On Tue 2018-01-30 10:38:38, Ladislav Michl wrote:
>>>>> On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
>>>>>> Hi,
>>>>>>
>>>>
>>>>>>> Well, notice I'm converting existing driver to device tree. And that
>>>>>>> one already has GPIO dependency. It is possible that more work needs
>>>>>>> to be done there, but that should not be a reason to delay this. Feel
>>>>>>> free to help.
>>>>>
>>>>> Adding DT properties that need to be maintained for compatibility reasons
>>>>> is a bad idea and very good reason to delay merging unfinished stuff.
>>>>> And meanwhile it turned out it is not power-gpio :)
>>>>
>>>> I believe reset-gpios and power-gpios are commonly used like
>>>> this... and that's what the old code does.
>>>
>>> Why do you care about old code when introducing new DT property?
>>> Either it is reset, then lets call it reset-gpios or it is power supply
>>> and then voltage regulator should be used (VAUX4.OUT is such a regulator
>>> although it is unclear to me how it is controlled (*)).
>>
>> power gpio = !reset gpio. Difference is only in polarity.
> 
> Quick grep:
> Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> - power-gpios: GPIO to control the PWRDWN pin
> - reset-gpios: GPIO to control the RESET pin
> Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> - ti,power-gpio :     GPIO connected to chip's PMEN pin
> Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> - power-gpios             : Specification for the pin connected to the gsl1680's
>                             shutdown input. This needs to be driven high to take the
>                             gsl1680 out of its low power state
> Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
> - power-gpios             : GPIO specification for the pin connected to the
>                             ektf2127's wake input. This needs to be driven high
>                             to take ektf2127 out of it's low power state
> 
> As you can see others are using it to drive pins different from nRESET. As
> stated in datasheet:
> "The TLV320DAC32 requires a hardware reset after power-up for proper operation.
> After all power supplies are at their specified values, the nRESET pin must be
> driven low for at least 10ns. If this reset sequence is not performed, the DAC32
> may not respond properly to register reads/writes". That does not sound like
> anything to do with power.
> 
> (It seems the only difference between TLV320DAC33 and TLV320DAC32 is uses a ball
> grid array package vs QFN32)

Note that tlv320dac32 != tlv320dac33, they are not even register
compatible devices... dac33 was created _for_ Nokia back in the days and
as far as I know there is no publicly available documentation for dac33.

And yes, my pick to use power_gpio in the code was wrong, it should have
been named as reset_gpio.

> 
>>>> You are not helping.
>>>
>>> The only way I can help here is to resend your patch with "reset-gpios"
>>> used, which I'm pretty sure you can handle yourself.
>>
>> Well, you can do that, and then you can argue with the next person who
>> feels one of the properties has to get his preferred color. Hard part
>> is not changing code :-(.
> 
> Indeed, hard part is not to break DT compatibility later. Consider someone
> will have to add regulator support later, which you omitted to do - having
> both power supply and power gpio is a bit confusing, don't you think?
> 
> Anyway, time to stop arguing, feel free to do what you think is right, I do
> not have anything important to add :)
> 
> 	ladis
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
new file mode 100644
index 0000000..6cbd311
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
@@ -0,0 +1,32 @@ 
+Texas Instruments - tlv320dac33 Codec module
+
+The tlv320dac33 serial control bus communicates through I2C protocols.
+
+Required properties:
+
+- compatible - "ti,tlv320dac33"
+- reg - I2C slave address
+
+Optional properties:
+
+- power-gpios - gpio pin to power the device, active high
+
+- interrupts       - The interrupt output from the device.
+- interrupt-parent - The parent interrupt controller.
+
+- ti,keep-bclk 	- Keep the BCLK running in FIFO modes
+- ti,burst-bclkdiv - BCLK divider value in burst mode
+
+Example:
+
+tlv320dac33: audio-codec@19 {
+	compatible = "ti,tlv320dac33";
+	reg = <0x19>;
+
+	interrupt-parent = <&gpio2>;
+	interrupts = <21 1>; /* gpio_53, IRQF_TRIGGER_RISING */
+	power-gpio = <&gpio2 28 0>; /* gpio_60 */
+
+	ti,keep-bclk;
+	ti,burst-bclkdiv = <3>;
+};
diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
index 5b94a15..2a0fe06 100644
--- a/sound/soc/codecs/tlv320dac33.c
+++ b/sound/soc/codecs/tlv320dac33.c
@@ -30,6 +32,7 @@ 
 #include <linux/interrupt.h>
 #include <linux/gpio.h>
 #include <linux/regulator/consumer.h>
+#include <linux/of_gpio.h>
 #include <linux/slab.h>
 #include <sound/core.h>
 #include <sound/pcm.h>
@@ -105,7 +108,7 @@  struct tlv320dac33_priv {
 	unsigned int nsample;		/* burst read amount from host */
 	int mode1_latency;		/* latency caused by the i2c writes in
 					 * us */
-	u8 burst_bclkdiv;		/* BCLK divider value in burst mode */
+	u32 burst_bclkdiv;		/* BCLK divider value in burst mode */
 	unsigned int burst_rate;	/* Interface speed in Burst modes */
 
 	int keep_bclk;			/* Keep the BCLK continuously running
@@ -1484,16 +1487,11 @@  static struct snd_soc_dai_driver dac33_dai = {
 static int dac33_i2c_probe(struct i2c_client *client,
 			   const struct i2c_device_id *id)
 {
-	struct tlv320dac33_platform_data *pdata;
+	struct tlv320dac33_platform_data *pdata = client->dev.platform_data;
 	struct tlv320dac33_priv *dac33;
+	struct device_node *np = client->dev.of_node;
 	int ret, i;
 
-	if (client->dev.platform_data == NULL) {
-		dev_err(&client->dev, "Platform data not set\n");
-		return -ENODEV;
-	}
-	pdata = client->dev.platform_data;
-
 	dac33 = devm_kzalloc(&client->dev, sizeof(struct tlv320dac33_priv),
 			     GFP_KERNEL);
 	if (dac33 == NULL)
@@ -1505,10 +1503,26 @@  static int dac33_i2c_probe(struct i2c_client *client,
 
 	i2c_set_clientdata(client, dac33);
 
-	dac33->power_gpio = pdata->power_gpio;
-	dac33->burst_bclkdiv = pdata->burst_bclkdiv;
-	dac33->keep_bclk = pdata->keep_bclk;
-	dac33->mode1_latency = pdata->mode1_latency;
+	if (pdata) {
+		dac33->power_gpio = pdata->power_gpio;
+		dac33->burst_bclkdiv = pdata->burst_bclkdiv;
+		dac33->keep_bclk = pdata->keep_bclk;
+		dac33->mode1_latency = pdata->mode1_latency;
+	} else if (np) {
+		ret = of_get_named_gpio(np, "power-gpios", 0);
+		if (ret >= 0)
+			dac33->power_gpio = ret;
+		else
+			dac33->power_gpio = -1;
+
+		if (of_property_read_bool(np, "ti,keep-bclk"))
+			dac33->keep_bclk = true;
+
+		of_property_read_u32(np, "ti,burst-bclkdiv", &dac33->burst_bclkdiv);
+	} else {
+		dev_err(&client->dev, "Platform data not set\n");
+		return -ENODEV;
+	}
 	if (!dac33->mode1_latency)
 		dac33->mode1_latency = 10000; /* 10ms */
 	dac33->irq = client->irq;
@@ -1574,9 +1588,16 @@  static const struct i2c_device_id tlv320dac33_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, tlv320dac33_i2c_id);
 
+static const struct of_device_id tlv320dac33_of_match[] = {
+	{ .compatible = "ti,tlv320dac33", },
+	{},
+};
+MODULE_DEVICE_TABLE(i2c, tlv320dac33_of_match);
+
 static struct i2c_driver tlv320dac33_i2c_driver = {
 	.driver = {
 		.name = "tlv320dac33-codec",
+		.of_match_table = of_match_ptr(tlv320dac33_of_match),
 	},
 	.probe		= dac33_i2c_probe,
 	.remove		= dac33_i2c_remove,