Patchwork ARM: LPC32xx: Provide DMA filter callbacks via platform data

login
register
mail settings
Submitter stigge@antcom.de
Date Aug. 16, 2012, 1:15 p.m.
Message ID <1345122935-22115-1-git-send-email-stigge@antcom.de>
Download mbox | patch
Permalink /patch/177987/
State New
Headers show

Comments

stigge@antcom.de - Aug. 16, 2012, 1:15 p.m.
The SLC and MLC NAND drivers now need their dma_filter callbacks via platform
data to make them independent of single DMA engine drivers.

(This also helps fixing build errors of the SLC and MLC drivers when building
as modules because direct access to AMBA dma filter functions isn't available
via export.)

Signed-off-by: Roland Stigge <stigge@antcom.de>

---

Applies to v3.6-rc1

 arch/arm/mach-lpc32xx/phy3250.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)
Arnd Bergmann - Aug. 16, 2012, 1:59 p.m.
On Thursday 16 August 2012, Roland Stigge wrote:
> The SLC and MLC NAND drivers now need their dma_filter callbacks via platform
> data to make them independent of single DMA engine drivers.
> 
> (This also helps fixing build errors of the SLC and MLC drivers when building
> as modules because direct access to AMBA dma filter functions isn't available
> via export.)
> 
> Signed-off-by: Roland Stigge <stigge@antcom.de>

Yes, this looks right.

Acked-by: Arnd Bergmann <arnd@arndb.de>

Once we have proper DT bindings for the DMA channels, we can hopefully
get rid of the auxdata again.

	Arnd
Artem Bityutskiy - Aug. 17, 2012, 10:09 a.m.
On Thu, 2012-08-16 at 15:15 +0200, Roland Stigge wrote:
> The SLC and MLC NAND drivers now need their dma_filter callbacks via platform
> data to make them independent of single DMA engine drivers.
> 
> (This also helps fixing build errors of the SLC and MLC drivers when building
> as modules because direct access to AMBA dma filter functions isn't available
> via export.)
> 
> Signed-off-by: Roland Stigge <stigge@antcom.de>

Pushed the 3 patches to l2-mtd.git, thanks!
stigge@antcom.de - Aug. 17, 2012, 10:52 a.m.
On 08/17/2012 12:09 PM, Artem Bityutskiy wrote:
> On Thu, 2012-08-16 at 15:15 +0200, Roland Stigge wrote:
>> The SLC and MLC NAND drivers now need their dma_filter callbacks
>> via platform data to make them independent of single DMA engine
>> drivers.
>> 
>> (This also helps fixing build errors of the SLC and MLC drivers
>> when building as modules because direct access to AMBA dma filter
>> functions isn't available via export.)
>> 
>> Signed-off-by: Roland Stigge <stigge@antcom.de>
> 
> Pushed the 3 patches to l2-mtd.git, thanks!

To later avoid collisions on subsystem merge, can you please leave the
patch with arch/arm/mach-lpc32xx/phy3250.c for arm-soc.git? (I will
provide a pull request for Arnd and Olof, as usual.)

Thanks,

Roland
Artem Bityutskiy - Aug. 17, 2012, 11:01 a.m.
On Fri, 2012-08-17 at 12:52 +0200, Roland Stigge wrote:
> On 08/17/2012 12:09 PM, Artem Bityutskiy wrote:
> > On Thu, 2012-08-16 at 15:15 +0200, Roland Stigge wrote:
> >> The SLC and MLC NAND drivers now need their dma_filter callbacks
> >> via platform data to make them independent of single DMA engine
> >> drivers.
> >> 
> >> (This also helps fixing build errors of the SLC and MLC drivers
> >> when building as modules because direct access to AMBA dma filter
> >> functions isn't available via export.)
> >> 
> >> Signed-off-by: Roland Stigge <stigge@antcom.de>
> > 
> > Pushed the 3 patches to l2-mtd.git, thanks!
> 
> To later avoid collisions on subsystem merge, can you please leave the
> patch with arch/arm/mach-lpc32xx/phy3250.c for arm-soc.git? (I will
> provide a pull request for Arnd and Olof, as usual.)

Only if Arnd insists. Otherwise I'd prefer to resolve collisions (they
cannot be hard with this patch) than pulling the soc tree to the mtd
tree.
Artem Bityutskiy - Aug. 17, 2012, 11:10 a.m.
On Fri, 2012-08-17 at 14:01 +0300, Artem Bityutskiy wrote:
> > To later avoid collisions on subsystem merge, can you please leave the
> > patch with arch/arm/mach-lpc32xx/phy3250.c for arm-soc.git? (I will
> > provide a pull request for Arnd and Olof, as usual.)
> 
> Only if Arnd insists. Otherwise I'd prefer to resolve collisions (they
> cannot be hard with this patch) than pulling the soc tree to the mtd
> tree.

Actually the mtd patches do not compile-depend on it, sorry, I am
dropping it from the MTD tree. Thanks!
Arnd Bergmann - Aug. 17, 2012, 11:40 a.m.
On Friday 17 August 2012, Artem Bityutskiy wrote:
>   Show Details
>   On Fri, 2012-08-17 at 14:01 +0300, Artem Bityutskiy wrote:
> > > To later avoid collisions on subsystem merge, can you please leave the
> > > patch with arch/arm/mach-lpc32xx/phy3250.c for arm-soc.git? (I will
> > > provide a pull request for Arnd and Olof, as usual.)
> > 
> > Only if Arnd insists. Otherwise I'd prefer to resolve collisions (they
> > cannot be hard with this patch) than pulling the soc tree to the mtd
> > tree.
> 
> Actually the mtd patches do not compile-depend on it, sorry, I am
> dropping it from the MTD tree. Thanks!

For reference, I'm fine with either outcome, I don't mind seeing an
occasional collision with subsystem trees, as they tend to be trivial
to resolve.

If you split a series to go through multiple git trees, you have to
ensure that both halves are actually regression free by themselves,
which typically ends up being much harder than fixing a small merge
conflict.

	Arnd
stigge@antcom.de - Aug. 17, 2012, 11:45 a.m.
On 08/17/2012 01:40 PM, Arnd Bergmann wrote:
>> Actually the mtd patches do not compile-depend on it, sorry, I am
>> dropping it from the MTD tree. Thanks!
> 
> For reference, I'm fine with either outcome, I don't mind seeing an
> occasional collision with subsystem trees, as they tend to be trivial
> to resolve.
> 
> If you split a series to go through multiple git trees, you have to
> ensure that both halves are actually regression free by themselves,

Of course. But in this very case, they are. So I'd prefer pushing them
via different trees because I have other patches for mach-lpc32xx in the
queue and would like to minimize work for you. :-)

Roland

Patch

--- linux-2.6.orig/arch/arm/mach-lpc32xx/phy3250.c
+++ linux-2.6/arch/arm/mach-lpc32xx/phy3250.c
@@ -37,6 +37,8 @@ 
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/clk.h>
+#include <linux/mtd/lpc32xx_slc.h>
+#include <linux/mtd/lpc32xx_mlc.h>
 
 #include <asm/setup.h>
 #include <asm/mach-types.h>
@@ -223,6 +225,14 @@  static struct mmci_platform_data lpc32xx
 	 * gather, and the MMCI driver doesn't do it this way */
 };
 
+static struct lpc32xx_slc_platform_data lpc32xx_slc_data = {
+	.dma_filter = pl08x_filter_id,
+};
+
+static struct lpc32xx_mlc_platform_data lpc32xx_mlc_data = {
+	.dma_filter = pl08x_filter_id,
+};
+
 static const struct of_dev_auxdata lpc32xx_auxdata_lookup[] __initconst = {
 	OF_DEV_AUXDATA("arm,pl022", 0x20084000, "dev:ssp0", &lpc32xx_ssp0_data),
 	OF_DEV_AUXDATA("arm,pl022", 0x2008C000, "dev:ssp1", &lpc32xx_ssp1_data),
@@ -230,6 +240,10 @@  static const struct of_dev_auxdata lpc32
 	OF_DEV_AUXDATA("arm,pl080", 0x31000000, "pl08xdmac", &pl08x_pd),
 	OF_DEV_AUXDATA("arm,pl18x", 0x20098000, "20098000.sd",
 		       &lpc32xx_mmci_data),
+	OF_DEV_AUXDATA("nxp,lpc3220-slc", 0x20020000, "20020000.flash",
+		       &lpc32xx_slc_data),
+	OF_DEV_AUXDATA("nxp,lpc3220-mlc", 0x200a8000, "200a8000.flash",
+		       &lpc32xx_mlc_data),
 	{ }
 };