public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: lamikr <lamikr@cc.jyu.fi>
To: "Menon, Nishanth" <x0nishan@ti.com>
Cc: OMAP-Linux <linux-omap-open-source@linux.omap.com>
Subject: Re: [PATCH] Alsa modularisations and support for tsc2101 2/7
Date: Wed, 22 Feb 2006 01:53:10 +0200	[thread overview]
Message-ID: <43FBA7E6.2080103@cc.jyu.fi> (raw)
In-Reply-To: <520AB2AD990DC04082102F77CA1726381036EF@dlee03.ent.ti.com>


>>You mean the codec files moving to sound/ ? With this board file
>>approach this cause problems in linking the codec functions in the
>>board file. They had to stay in the omap tree not in the sound/ .
>>Maybe a better place to them could be plat-omap/ ?
>>    
>>
>I dont see plat-omap having stuff other than omap specific code - such as dma etc.. if we put peripheral chip specific code there, i dont see kernel directory's abstraction happening properly sound/.. is the perfect place for this. The issue of linking is a minor problem - which can be handled by using proper include files.
>Regards,
>  
>
Hi,

We have put the audio codec files under /arm/arch because we have wanted
to share the same omap-alsa.c between both codecs.
And for that reason we need to set the function pointers to omap-alsa.c
so that the calls from omap-alsa.c ends up to correct codec.

We have tried to do couple of different method for implementing this and
have not sofar found any perfect solution.

In our first attempt we kept all alsa related files in sound/arm/omap
directory.
In addition we put get_codec_functions() method to both of the drivers
and when the module was loaded the omap-alsa.c
called this get_codec_functions() method. The method had one
disadvantage, user could not build aic23 and tsc2101 drivers to same kernel
as both of the drivers had this one function with the same name.

In our second attemt (the one included in patches) we put the board-code
to set the function pointers. The drawback in this
method is that the functions defined in the board-code must itself be
linked within the board-code, otherwise we
got linking errors in the end.

Third (non tested) alternative could work in the following way
- Move the alsa modules probe method to codecs.
- when probe is called, it could define the function pointers and set
them to omap-alsa.c

Fourth possibility I know would be to make own implementation from
omap-alsa.c both for both of the codecs
but that is something I would like to avoid.

So if you have some idea how to do this, can you give us some info how
to do that.

Mika

  reply	other threads:[~2006-02-21 23:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-20 17:47 [PATCH] Alsa modularisations and support for tsc2101 2/7 Daniel Petrini
2006-02-21 13:31 ` Menon, Nishanth
2006-02-21 14:06   ` Daniel Petrini
2006-02-21 14:08     ` Menon, Nishanth
2006-02-21 23:53       ` lamikr [this message]
2006-02-22 18:15         ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43FBA7E6.2080103@cc.jyu.fi \
    --to=lamikr@cc.jyu.fi \
    --cc=linux-omap-open-source@linux.omap.com \
    --cc=x0nishan@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox