[U-Boot] [PATCH] mxs: mmc: spi: dma: Better wrap the MXS differences

[Marek Vasut]

Dear Stefano Babic,

> On 02/02/2013 06:55, Marek Vasut wrote:
> > This patch streamlines the differences between the MX23 and MX28 by
> > implementing a few helper functions to handle different DMA channel
> > mapping, different clock domain for SSP block and fixes a few minor
> > bugs.
> > 
> > First of all, the DMA channel mapping is now fixed in dma.h by defining
> > the actual channel map for both MX23 and MX28. Thus, MX23 now does no
> > longer use MX28 channel map which was wrong. Also, there is a fix for
> > MX28 DMA channel map, where the last four channels were incorrect.
> > 
> > Next, because correct DMA channel map is in place, the
> > mxs_dma_init_channel() call now bases the channel ID starting from SSP
> > port #0. This removes the need for DMA channel offset being added and
> > cleans up the code. For the same reason, the SSP0 offset can now be used
> > in mxs_dma_desc_append(), thus no need to adjust dma channel number in
> > the driver either.
> > 
> > Lastly, the SSP clock ID is now retrieved by calling
> > mxs_ssp_clock_by_bus() which handles the fact that MX23 has shared SSP
> > clock for both ports, while MX28 has per-port SSP clock.
> > 
> > Finally, the mxs_ssp_bus_id_valid() pulls out two implementations of the
> > same functionality from MMC and SPI driver into common code.
> > 
> > Signed-off-by: Marek Vasut <marex at denx.de>
> > Cc: Fabio Estevam <fabio.estevam at freescale.com>
> > Cc: Otavio Salvador <otavio at ossystems.com.br>
> > Cc: Stefano Babic <sbabic at denx.de>
> > ---
> > 
> >  arch/arm/include/asm/arch-mxs/dma.h      |   19 ++++++++++++++++++-
> >  arch/arm/include/asm/arch-mxs/regs-ssp.h |   26
> >  ++++++++++++++++++++++++++ drivers/mmc/mxsmmc.c                     |  
> >  20 ++++---------------- drivers/spi/mxs_spi.c                    |    4
> >  ++--
> >  4 files changed, 50 insertions(+), 19 deletions(-)
> > 
> > NOTE: COMPILE TESTED ONLY!!! I need someone to actually test this stuff.
> 
> Hi all,
> 
> I am thinking about how to proceed with this. Is there any plan to test
> it ? It would prefer that it runs at least once else merging it now
> without any test and fix later.

This needs more work, NAK so far.

Best regards,
Marek Vasut