On Thu, 2008-01-10 at 00:41 -0500, Jon Smirl wrote:
ASOC v2 is sitting on a Wolfson server out of tree. I have been using
it for several months without problem. The pace of it being merged
could probably be sped up.
I think we are probably looking at submission in the next 8 - 10 weeks.
Liam Girdwood wrote:
I think we are probably looking at submission in the next 8 - 10 weeks.
Currently most of the core code is complete, however some platforms and
codecs still need porting.
With that in mind, can I get some kind of consensus from the PPC side as to
whether this ASoC V1
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote:
Liam Girdwood wrote:
I think we are probably looking at submission in the next 8 - 10 weeks.
Currently most of the core code is complete, however some platforms and
codecs still need porting.
With that in mind, can I get some kind of
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote:
Grant Likely wrote:
The driver doesn't need to be 100% correct. Drivers are easy to
change if they aren't quite right. There are no long term
consequences.
However, the device tree issues must be addressed before it is merged
and
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?
The CS4270 driver is old style, which means
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?
The CS4270 driver is old style, which means
Jon Smirl wrote:
So the codec is controlled from the i2c bus and SSI is used to supply
it with data. Based on what has been said on this list, the device
tree node for the codec should be on the i2c bus with a link from the
ssi bus to it.
I'm working on that now. I'll have a new patch with
Grant Likely wrote:
Nit: node name should be either [EMAIL PROTECTED] (the mode that it is in), or
[EMAIL PROTECTED] (if you feel that this node encapsulates the concept of a
sound device enough).
Well, SSI stands for Synchronous Serial Interface (although it's capable of
asynchronous
On Mon, Jan 07, 2008 at 06:28:54PM +, Mark Brown wrote:
On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:
David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it
only becomes fully operational once the codec driver has registered
with it?
On 1/9/08, David Gibson [EMAIL PROTECTED] wrote:
On Mon, Jan 07, 2008 at 06:28:54PM +, Mark Brown wrote:
On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:
David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it
only becomes fully
On Fri, Jan 04, 2008 at 08:43:17PM -0600, Timur Tabi wrote:
Mark Brown wrote:
In other words, ...
clock1 = 0, bb8000
clock2 = 1, 653230
clock23 = 0, ab2372
Yes, something like that would cover it. I'm not sure what is idiomatic
for the device tree.
and of course the ordering matters.
On Sun, Jan 06, 2008 at 11:46:37AM +1100, David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it
only becomes fully operational once the codec driver has registered
with it?
That's what ASoC v2 is doing, more or less (the core brings things on
line rather than
David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it
only becomes fully operational once the codec driver has registered
with it?
Not in ASoC V1. You have to understand, ASoC V1 was designed without any
consideration for runtime-bindings and other OF
On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:
David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it
only becomes fully operational once the codec driver has registered
with it?
Not in ASoC V1. You have to understand, ASoC V1 was designed
Liam Girdwood wrote:
On Mon, 2008-01-07 at 09:52 -0600, Timur Tabi wrote:
So all I'm trying to do now is get my driver, with warts and all, into the
tree
so that I can focus with Liam et al to get a real ASoC V2 up and running.
I'll commit the MPC8610 into the ASoC (v1) dev tree soon
On Mon, 2008-01-07 at 09:52 -0600, Timur Tabi wrote:
So all I'm trying to do now is get my driver, with warts and all, into the
tree
so that I can focus with Liam et al to get a real ASoC V2 up and running.
I'll commit the MPC8610 into the ASoC (v1) dev tree soon (hopefully
tonight).
On Fri, Jan 04, 2008 at 08:39:54PM -0600, Timur Tabi wrote:
David Gibson wrote:
And what distinction are you drawing between first and second
here?
Oh, that's an easy one: The CS4270 can work without an I2C or SPI
connection,
but it will never work without an I2S connection.
On Fri, Jan 04, 2008 at 10:47:25AM +1100, David Gibson wrote:
On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote:
I'm no expert on this, but I think from the PowerPC point-of-view,
the *ideal* situation would be if the ASoC fabric driver were
generic, maybe even part of ASoC
David Gibson wrote:
And what distinction are you drawing between first and second
here?
Oh, that's an easy one: The CS4270 can work without an I2C or SPI connection,
but it will never work without an I2S connection.
Why would the I2S need to scan for codecs? Wouldn't it be up to the
Mark Brown wrote:
Each individual call to set_sysclk() only takes three parameters but it
can be called repeatedly and some configurations are going to require
this.
In other words, ...
clock1 = 0, bb8000
clock2 = 1, 653230
clock23 = 0, ab2372
and of course the ordering matters.
Ok,
Mark Brown wrote:
The machine support code (fabric driver in PowerPC terms, I think?)
tells the core how everything is connected together by registering
devices representing the links (eg, I2S) between the codecs, CPU and
other devices. The ASoC core is then responsible for ensuring that all
Mark Brown wrote:
clock1 = 0, bb8000
Would that be better?
To cover everything you'd need to be able to specify all the clocking
parameters, especially a PLL configuration, and also specify more than
one of each item. Even then you'd still have problems like...
The ASoC V1 API for
On Thu, Jan 03, 2008 at 12:23:08PM -0600, Timur Tabi wrote:
Mark Brown wrote:
To cover everything you'd need to be able to specify all the clocking
parameters, especially a PLL configuration, and also specify more than
one of each item. Even then you'd still have problems like...
The
On Thu, Jan 03, 2008 at 01:18:31PM -0600, Scott Wood wrote:
Grant Likely wrote:
Gah! Don't do that! Then you need to maintain both directions in the
dts file. Software is good at generating reverse mappings.
Software is, however, lousy at correctly wading through
poorly-structured
On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote:
Mark Brown wrote:
The machine support code (fabric driver in PowerPC terms, I think?)
tells the core how everything is connected together by registering
devices representing the links (eg, I2S) between the codecs, CPU and
other
On Wed, Jan 02, 2008 at 09:10:44AM -0600, Timur Tabi wrote:
Jon Smirl wrote:
Does this need to be bus-frequency? It's always called MCLK in all of
the literature.
I'm trying to make this node as generic as possible. The fabric driver
is the one that will parse this node and pass the
On Wed, Jan 02, 2008 at 09:28:12AM -0700, Grant Likely wrote:
On 1/2/08, Timur Tabi [EMAIL PROTECTED] wrote:
However, it doesn't make sense to have a node in the device tree for the
fabric driver, because there is no such device. The fabric driver is
an abstraction. So I need to chose
Lee Revell wrote:
Please use DMA_32BIT_MASK (see include/linux/dma-mapping.h) instead of
0x.
No prob. But did you see this comment:
/*
* NOTE: do not use the below macros in new code and do not add new
definitions
* here.
*
* Instead, just open-code DMA_BIT_MASK(n) within
At Thu, 20 Dec 2007 08:24:35 -0600,
Timur Tabi wrote:
+static int fsl_dma_new(struct snd_card *card, struct snd_soc_codec_dai
*dai,
+ struct snd_pcm *pcm)
+{
+ static u64 fsl_dma_dmamask = 0x;
+ int ret;
+
+ if (!card-dev-dma_mask)
+ card-dev-dma_mask =
Takashi Iwai wrote:
All? No, only a few...
For PCI, usually pci_set_dma_mask() and pci_set_consistent_dma_mask()
are used, of course.
Hmm, ok I was wrong. I took this code from the ASoC at91 driver.
Unfortunately, I don't understand what this code is trying to do. The AT91
driver isn't
On Dec 20, 2007 8:54 AM, Takashi Iwai [EMAIL PROTECTED] wrote:
At Thu, 20 Dec 2007 08:24:35 -0600,
Timur Tabi wrote:
+static int fsl_dma_new(struct snd_card *card, struct snd_soc_codec_dai
*dai,
+ struct snd_pcm *pcm)
+{
+ static u64 fsl_dma_dmamask = 0x;
+ int
31 matches
Mail list logo
