Re: [PATCH RFC 1/3] ASoC: uda1380: use callbacks instead of gpiolib

[Vasily Khoruzhick <anarsoul@gmail.com>]

[-- Attachment #1.1: Type: Text/Plain, Size: 1718 bytes --]

В сообщении от 26 июня 2010 19:40:37 автор Mark Brown написал:
> On 26 Jun 2010, at 16:14, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > Some machines require some tricks to enable/disable
> > codec, i.e. disable or enable i2s clock before enabling/disabling
> > codec, and just configuring gpio is not enough; some machines
> > have no reset pin (reset is performed on codec power on automatically).
> > Fix that issue by using machine-specific callback to enable codec power.
> > 
> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> 
> This is fine but it'd be really nice to preserve the use of GPIOs since
> that will cover the majority of machines - for example, by providing a
> default callback if none is provided and GPIOs are. This will also
> avoid the need to update existing machine drivers (which needs to be
> done otherwise).

The only machine that uses uda1380 and supported by mainline kernel is 
magician, rx1950 and h1940 sound support is not merged yet, so that's not a 
problem to perform that change.
 
> However, I do wonder if the more complex set_power() callbacks might
> not just end up as regulator API consumers?

Is it really necessary? Plain callback perfectly fits here, and same approach 
is used for s3cmci driver. For example, rx1950_uda1380_set_power is not 
complex and looks like this:

static void rx1950_uda1380_set_power(int enable)
{
	clk_disable(i2c_clk);
	gpio_direction_output(S3C2410_GPD(0), 0);
	gpio_direction_output(S3C2410_GPJ(0), enable);
	if (enable) {
		gpio_set_value(S3C2410_GPD(0), 1);
		mdelay(1);
		gpio_set_value(S3C2410_GPD(0), 0);
	}
	clk_enable(i2c_clk);
}

Regards
Vasily

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel