[PATCH] ASoC: pcm512x: Remove hardcoding of pll-lock to GPIO4

[PATCH] ASoC: pcm512x: Remove hardcoding of pll-lock to GPIO4

[Howard Mitchell]

Currently GPIO4 is hardcoded to output the pll-lock signal.
Unfortunately this is after the pll-out GPIO is configured which
is selectable in the device tree. Therefore it is not possible to
use GPIO4 for pll-out. Therefore this patch removes the
configuration of GPIO4.

Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk>
---
 sound/soc/codecs/pcm512x.c |   19 -------------------
 1 file changed, 19 deletions(-)

diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
index 8472099..5a30fdd 100644
--- a/sound/soc/codecs/pcm512x.c
+++ b/sound/soc/codecs/pcm512x.c
@@ -1296,25 +1296,6 @@ static int pcm512x_hw_params(struct snd_pcm_substream *substream,
 				ret, pcm512x->pll_out);
 			return ret;
 		}
-
-		gpio = PCM512x_G1OE << (4 - 1);
-		ret = regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_EN,
-					 gpio, gpio);
-		if (ret != 0) {
-			dev_err(codec->dev, "Failed to enable gpio %d: %d\n",
-				4, ret);
-			return ret;
-		}
-
-		gpio = PCM512x_GPIO_OUTPUT_1 + 4 - 1;
-		ret = regmap_update_bits(pcm512x->regmap, gpio,
-					 PCM512x_GxSL, PCM512x_GxSL_PLLLK);
-		if (ret != 0) {
-			dev_err(codec->dev,
-				"Failed to output pll lock on %d: %d\n",
-				ret, 4);
-			return ret;
-		}
 	}
 
 	ret = regmap_update_bits(pcm512x->regmap, PCM512x_SYNCHRONIZE,
-- 
1.7.9.5

Re: [PATCH] ASoC: pcm512x: Remove hardcoding of pll-lock to GPIO4

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Mon, Mar 23, 2015 at 09:17:01PM +0000, Howard Mitchell wrote:
> Currently GPIO4 is hardcoded to output the pll-lock signal.
> Unfortunately this is after the pll-out GPIO is configured which
> is selectable in the device tree. Therefore it is not possible to
> use GPIO4 for pll-out. Therefore this patch removes the
> configuration of GPIO4.

Applied, thanks.  Please pay attention to your CC lists - try to avoid
CC irrelevant people on your mails.  This helps cut down on people's
mail loads.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

RE: [PATCH] ASoC: pcm512x: Remove hardcoding of pll-lock to GPIO4

[Peter Rosin]

Howard Mitchell wrote:
> Currently GPIO4 is hardcoded to output the pll-lock signal.
> Unfortunately this is after the pll-out GPIO is configured which
> is selectable in the device tree. Therefore it is not possible to
> use GPIO4 for pll-out. Therefore this patch removes the
> configuration of GPIO4.

Howard, thanks for picking up my laundry!

Is master mode working for you otherwise? Have you seen any sign
of bad dividers for the various clocks, or anything like that?

Regarding the pin configuration, I suppose the cleanest approach
would be to implement it as a pin control driver? Then you could
also expose the pins as gpios and  select the pin functions in a more
standard way, right? I wouldn't know where to start with that
though. I have the feeling that it would also mean that there would
have to be a mfd driver for the chip???

However, there is the issue that we don't need anything more from
the chip, so we're happy with the driver as is (assuming the overclocking
patch goes in as planned for 4.1).

Cheers,
Peter

Re: [PATCH] ASoC: pcm512x: Remove hardcoding of pll-lock to GPIO4

[Howard Mitchell]

On 24/03/15 07:52, Peter Rosin wrote:
> Howard Mitchell wrote:
>> Currently GPIO4 is hardcoded to output the pll-lock signal.
>> Unfortunately this is after the pll-out GPIO is configured which
>> is selectable in the device tree. Therefore it is not possible to
>> use GPIO4 for pll-out. Therefore this patch removes the
>> configuration of GPIO4.
> Howard, thanks for picking up my laundry!
No problem. It was pretty quick and easy to redo from my previous patch 
anyway.
> Is master mode working for you otherwise? Have you seen any sign
> of bad dividers for the various clocks, or anything like that?
Not so far. I've run though all the sampling rates from 44.1KHz to 
192KHz with a 24.576MHz input clock and they all sounded ok. I haven't 
done the maths and checked every single divider setting but I think I 
would have heard if something wasn't quite right.
> Regarding the pin configuration, I suppose the cleanest approach
> would be to implement it as a pin control driver? Then you could
> also expose the pins as gpios and  select the pin functions in a more
> standard way, right? I wouldn't know where to start with that
> though. I have the feeling that it would also mean that there would
> have to be a mfd driver for the chip???
Yes that would allow userspace access as well. I guess a good place to 
start would be one of the I2C gpio expanders: 
.../drivers_/_gpio_/_gpio-pca953x.c for instance.
> However, there is the issue that we don't need anything more from
> the chip, so we're happy with the driver as is (assuming the overclocking
> patch goes in as planned for 4.1).
On our board the additional gpios are not even tracked out so the driver 
is fine as is for now. For the future we have discussed the possibility 
of providing two master clock oscillators to avoid using the pll 
altogether. In this case one of the gpios could be used for switching.

- Howard