[alsa-devel] [PATCH 2/4] mmp: support ssp in pxa168
On Wed, Mar 10, 2010 at 08:14:42AM -0500, Haojian Zhuang wrote:
From 75fe4b02234f6476e72827508f11f1035d7aaf68 Mon Sep 17 00:00:00 2001 From: Haojian Zhuang haojian.zhuang@marvell.com Date: Wed, 10 Mar 2010 06:32:43 -0500 Subject: [PATCH] [ARM] mmp: support ssp in pxa168
Support ssp in pxa168. The basic function of SSP is same as pxa, but clock source and IRQ is changed.
Signed-off-by: Haojian Zhuang haojian.zhuang@marvell.com
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
That said might it make sense to merge this and the previous patch via ASoC since there's new drivers using this following on and Liam's multi-codec work is likely to be creating merge issues this development cycle? I can apply the patches on a branch by themselves which can also be pulled into the PXA tree if needed.
On Wed, Mar 10, 2010 at 10:28 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, Mar 10, 2010 at 08:14:42AM -0500, Haojian Zhuang wrote:
From 75fe4b02234f6476e72827508f11f1035d7aaf68 Mon Sep 17 00:00:00 2001 From: Haojian Zhuang haojian.zhuang@marvell.com Date: Wed, 10 Mar 2010 06:32:43 -0500 Subject: [PATCH] [ARM] mmp: support ssp in pxa168
Support ssp in pxa168. The basic function of SSP is same as pxa, but clock source and IRQ is changed.
Signed-off-by: Haojian Zhuang haojian.zhuang@marvell.com
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
That said might it make sense to merge this and the previous patch via ASoC since there's new drivers using this following on and Liam's multi-codec work is likely to be creating merge issues this development cycle? I can apply the patches on a branch by themselves which can also be pulled into the PXA tree if needed.
I'd expect there to be some merge conflicts I need to solve along with my cleaning up of the SSP code. That said, it's better to go via -pxa tree and get the multi-codec work solved in linux-next?
Mark, could you please point me the reference to the multi-codec work so I can have a rough feeling of the possible merge issues?
- eric
On Thu, Mar 11, 2010 at 04:20:35PM +0800, Eric Miao wrote:
On Wed, Mar 10, 2010 at 10:28 PM, Mark Brown
cycle? I can apply the patches on a branch by themselves which can also be pulled into the PXA tree if needed.
I'd expect there to be some merge conflicts I need to solve along with my cleaning up of the SSP code. That said, it's better to go via -pxa tree and get the multi-codec work solved in linux-next?
That's not going to be possible with at least the machine driver - if it's only present in one tree we can't do fixups in the other. This is why I'm saying put it on a branch and merge it into both trees, that way both trees have the code in them as though things had been merged into mainline already so problems are much less likely.
Mark, could you please point me the reference to the multi-codec work so I can have a rough feeling of the possible merge issues?
There's a branch in Liam's git tree (still sketching out the goal rather than the finished product):
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git
Big thing is that there's most likely going to be at least cosmetic changes to how cards are registered.
On Thu, 2010-03-11 at 10:58 +0000, Mark Brown wrote:
On Thu, Mar 11, 2010 at 04:20:35PM +0800, Eric Miao wrote:
On Wed, Mar 10, 2010 at 10:28 PM, Mark Brown
cycle? I can apply the patches on a branch by themselves which can also be pulled into the PXA tree if needed.
I'd expect there to be some merge conflicts I need to solve along with my cleaning up of the SSP code. That said, it's better to go via -pxa tree and get the multi-codec work solved in linux-next?
That's not going to be possible with at least the machine driver - if it's only present in one tree we can't do fixups in the other. This is why I'm saying put it on a branch and merge it into both trees, that way both trees have the code in them as though things had been merged into mainline already so problems are much less likely.
Mark, could you please point me the reference to the multi-codec work so I can have a rough feeling of the possible merge issues?
There's a branch in Liam's git tree (still sketching out the goal rather than the finished product):
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc-2.6.git
Big thing is that there's most likely going to be at least cosmetic changes to how cards are registered.
Just to add, this is very experimental stuff in here atm (it will change and be rebased a lot!). I'm going over a few different approaches to see what fits best. I'll make proper announcement when Mark and I are happy with the general flow of the multic-codec work
Btw, time frame for this stuff is around 2.6.36.
Liam
On Wed, Mar 10, 2010 at 9:14 PM, Haojian Zhuang haojian.zhuang@gmail.com wrote:
From 75fe4b02234f6476e72827508f11f1035d7aaf68 Mon Sep 17 00:00:00 2001 From: Haojian Zhuang haojian.zhuang@marvell.com Date: Wed, 10 Mar 2010 06:32:43 -0500 Subject: [PATCH] [ARM] mmp: support ssp in pxa168
Support ssp in pxa168. The basic function of SSP is same as pxa, but clock source and IRQ is changed.
Haojian,
Could you please help rebase this against my 'ssp_cleanup' branch?
participants (4)
-
Eric Miao -
Haojian Zhuang -
Liam Girdwood -
Mark Brown