[alsa-devel] [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers
A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual DMA channel nodes, so the DMA controller nodes' compatible string must be listed in mpc8610_ids[] for the probe to work.
Also remove the "gianfar" compatible from mpc8610_ids[], since there is no gianfar (or any other networking device) on the 8610.
Signed-off-by: Timur Tabi timur@freescale.com ---
Kumar, the ASoC mainters are willing to pick up this patch, but they want an ACK from you first. Or, you could pick it up, since by itself it's harmless.
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c index 5abe137..018cc67 100644 --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c @@ -83,7 +83,8 @@ static struct of_device_id __initdata mpc8610_ids[] = { { .compatible = "fsl,mpc8610-immr", }, { .compatible = "fsl,mpc8610-guts", }, { .compatible = "simple-bus", }, - { .compatible = "gianfar", }, + /* So that the DMA channel nodes can be probed individually: */ + { .compatible = "fsl,eloplus-dma", }, {} };
On Mon, May 03, 2010 at 04:54:15PM -0500, Timur Tabi wrote:
{ .compatible = "simple-bus", },
- { .compatible = "gianfar", },
- /* So that the DMA channel nodes can be probed individually: */
- { .compatible = "fsl,eloplus-dma", }, {}
The removal of gianfar looks a bit surprising here - if it's not a mistake a note in the changelog would be useful.
Mark Brown wrote:
On Mon, May 03, 2010 at 04:54:15PM -0500, Timur Tabi wrote:
{ .compatible = "simple-bus", },
- { .compatible = "gianfar", },
- /* So that the DMA channel nodes can be probed individually: */
- { .compatible = "fsl,eloplus-dma", }, {}
The removal of gianfar looks a bit surprising here - if it's not a mistake a note in the changelog would be useful.
The changelog says this:
Also remove the "gianfar" compatible from mpc8610_ids[], since there is no gianfar (or any other networking device) on the 8610.
The 8610 is almost unique among our high-end PowerPC chips in that it literally has no on-board networking. The board provides networking via a PCI device.
On Tue, May 04, 2010 at 10:11:34AM -0500, Timur Tabi wrote:
Also remove the "gianfar" compatible from mpc8610_ids[], since there is no gianfar (or any other networking device) on the 8610.
Meh, sorry. Though this is a very good example of why you shouldn't randomly mix unrelated changes into one patch :)
On May 3, 2010, at 4:54 PM, Timur Tabi wrote:
A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual DMA channel nodes, so the DMA controller nodes' compatible string must be listed in mpc8610_ids[] for the probe to work.
Also remove the "gianfar" compatible from mpc8610_ids[], since there is no gianfar (or any other networking device) on the 8610.
Signed-off-by: Timur Tabi timur@freescale.com
Acked-by: Kumar Gala galak@kernel.crashing.org
- k
On Tue, May 04, 2010 at 12:20:13PM -0500, Kumar Gala wrote:
On May 3, 2010, at 4:54 PM, Timur Tabi wrote:
A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual DMA channel nodes, so the DMA controller nodes' compatible string must be listed in mpc8610_ids[] for the probe to work.
Also remove the "gianfar" compatible from mpc8610_ids[], since there is no gianfar (or any other networking device) on the 8610.
Signed-off-by: Timur Tabi timur@freescale.com
Acked-by: Kumar Gala galak@kernel.crashing.org
Just looking at the scheduling here with regard to the merge window and the fact that this doesn't seem to hurt the existing drivers perhaps it makes sense to merge this via the PowerPC tree immediately?
On Wed, May 5, 2010 at 6:22 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
Just looking at the scheduling here with regard to the merge window and the fact that this doesn't seem to hurt the existing drivers perhaps it makes sense to merge this via the PowerPC tree immediately?
Aren't we a little late in the cycle for a patch that doesn't do anything?
I was expecting this patch to go into Liam's tree.
On Wed, May 05, 2010 at 06:39:01AM -0500, Timur Tabi wrote:
On Wed, May 5, 2010 at 6:22 AM, Mark Brown
Just looking at the scheduling here with regard to the merge window and the fact that this doesn't seem to hurt the existing drivers perhaps it makes sense to merge this via the PowerPC tree immediately?
Aren't we a little late in the cycle for a patch that doesn't do anything?
It seems to be safe enough for -next.
Mark Brown wrote:
On Wed, May 05, 2010 at 06:39:01AM -0500, Timur Tabi wrote:
On Wed, May 5, 2010 at 6:22 AM, Mark Brown
Just looking at the scheduling here with regard to the merge window and the fact that this doesn't seem to hurt the existing drivers perhaps it makes sense to merge this via the PowerPC tree immediately?
Aren't we a little late in the cycle for a patch that doesn't do anything?
It seems to be safe enough for -next.
Sure, -next is fine.
participants (3)
-
Kumar Gala -
Mark Brown -
Timur Tabi