From: Mark Brown <broonie@sirena.org.uk>
To: Troy Kisky <troy.kisky@boundarydevices.com>
Cc: alsa-devel@alsa-project.org, Arun KS <arunks@mistralsolutions.com>
Subject: Re: [PATCH 0/5] [RFC] ALSA ASoC Support for TLVaic23b audio codec
Date: Mon, 29 Sep 2008 19:30:46 +0100 [thread overview]
Message-ID: <20080929183045.GA21010@sirena.org.uk> (raw)
In-Reply-To: <48E11753.3090100@boundarydevices.com>
On Mon, Sep 29, 2008 at 10:58:43AM -0700, Troy Kisky wrote:
> Mark Brown wrote:
> > Neither is board specific - there's no sense in having each board that
> > needs SPI support replicate the code to register a SPI device and do the
> > marshalling of data for SPI writes. What motivation do you see for not
> > doing that?
> It just doesn't seem to be logically a part of the codec code. And I didn't register
The data marshalling is a function of the codec hardware - whatever it
has been hooked up to the register address and data values written are
going to need to be in a given format when they hit the codec. The SPI
and I2C APIs abstract away the details of the actual controller from the
codec driver.
> an spi device. I just linked the simple spi routines with my board code (separate file).
I'm not sure which simple SPI API you're referring to here? In any
case, ASoC is shortly going to pretty much require a struct device for
the codec so it will be required to have a device of some kind
registered.
> Plus, it seems a lot of code duplication if each codec registers the spi device
> and I2C device. Are there more boards, or more codecs???
In the device model the board registers the *device*, the codec (or
whatever) driver registers the *driver* - the two are separated. The
driver core then instantiates the drivers based on what the board
specifies. There's not really any overlap between the two areas that I
can see.
Otherwise could you explain in more detail where you see the code
duplication coming from?
next prev parent reply other threads:[~2008-09-29 18:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-29 9:41 [PATCH 0/5] [RFC] ALSA ASoC Support for TLVaic23b audio codec Arun KS
2008-09-29 16:47 ` Troy Kisky
2008-09-29 16:54 ` Mark Brown
2008-09-29 17:05 ` Troy Kisky
2008-09-29 17:32 ` Mark Brown
2008-09-29 17:27 ` Troy Kisky
2008-09-29 17:39 ` Mark Brown
2008-09-29 17:58 ` Troy Kisky
2008-09-29 18:30 ` Mark Brown [this message]
2008-09-29 19:07 ` Troy Kisky
2008-09-29 19:50 ` Mark Brown
2008-09-29 21:15 ` Troy Kisky
-- strict thread matches above, loose matches on Subject: below --
2008-09-29 9:41 Arun KS
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=20080929183045.GA21010@sirena.org.uk \
--to=broonie@sirena.org.uk \
--cc=alsa-devel@alsa-project.org \
--cc=arunks@mistralsolutions.com \
--cc=troy.kisky@boundarydevices.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.