[alsa-devel] [RFC] Break up the patch_sigmatel.c

[Takashi Iwai]

At Thu, 13 Aug 2009 10:34:37 +0300,
Maxim Levitsky wrote:
> 
> On Thu, 2009-08-13 at 07:28 +0200, Takashi Iwai wrote: 
> > At Wed, 12 Aug 2009 23:35:45 +0300,
> > Maxim Levitsky wrote:
> > > 
> > > Hi folks,
> > > 
> > > I own an stac9227 and with latest kernel, it doesn't output any sound
> > > via front headphones. (this a is desktop)
> > 
> > OK, that could be my recent changes.
> > Could you give alsa-info.sh output, at best, on the working and
> > non-working states?
> 
> Oh, its was my mistake.
> in short I thought that I installed the alsa git tree, but it turns out
> that I was using the kernel drivers. alsa git drivers doesn't have this
> bug anymore.
> 
> The long explanation of this my mistake was that I first installed alsa
> drivers, but forgot, and installed kernel, which overwrite them.

Heh, good to hear that it's OK :)

> > > I don't want to bother you with details, etc, I will fix that myself. I
> > > have good knowledge of the device.
> > > 
> > > However, the mess that is patch_sigmatel.c seems to be doubled. 
> > > its huge file, and there are loads on new codecs added.
> > > 
> > > I have a suggestion, to break it up into smaller files.
> > > I especially want to move all 'data' from it to header file, and sort it
> > > by model. 
> > 
> > The "data" shouldn't be in header files in general...
> > 
> > > Maybe move pin configs to separate file.
> > 
> > This could be good.
> > 
> > > Also I know that stac9200 is quite old, and uses many different support
> > > functions. I could move these in another file as well.
> > > 
> > > In other words, I want to break it up into several (5 maybe) files,
> > > while not touching the code itself (I so that later maybe)
> > > 
> > > Since it is quite dirty and hard work, I want to ask if you agree.
> > 
> > It's open source, feel free to do it.
> 
> nice, I actually asked about this just for one reason, back when I send
> my patches to this driver, I think I tried to do something similar, but
> it was rejected or so.

Hm, I don't remember exactly, but splitting to files would be OK.
But splitting to separate modules again would result in more exports,
name space problems.  So, splitting to files and including from the
main *.c is a reasonable compromise, I think.

> And another note.
> Back in time, when I knew that driver well, back and front outputs were
> handled by same DAC, and it happened to be DAC0. This DAC is connected
> via analog loopback to ADC0.
> 
> Now front output is connected to another DAC, so loopback works only for
> back output. However I can control the volume of front and back channels
> separately, and don't know which feature I need more now (I don't use my
> tv card often any more nowadays)
> 
> Maybe add a codec hint for that?

Sounds like a good idea.


> > > Btw, half of static data can be retrieved from codec by querying it
> > > (like dac,adc,pin node ids)
> > 
> > Yes.
> > 
> Indeed.
> 
> 
> I think that the best solution to all hda problems, it once and for all
> write a generic driver for all codecs, and put pin configs in, a
> 'firmware' file (this is already done?)

Yeah, that's my dream.  The "firmware" stuff is already there, provided
as "patch" parameter.

> Most of things can be retrieved from verb responses + pin configs
> 
> 
> Why not?

Just because the parsing the all possible codec connections is no
trivial task.  Many codecs have connections between pin and DAC
through different multiple routes, one for direct, one over analog
mixer, and SPDIF loopback, etc.  It's especially for older codecs
that inherit the design from old days, such as ALC88x, CMI codecs
and AD1986A / AD1988.


thanks,

Takashi