Message ID | 1427370354-21247-5-git-send-email-ben.dooks@codethink.co.uk (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Around Thu 26 Mar 2015 11:45:52 +0000 or thereabout, Ben Dooks wrote: > Use <linux/atmel_io.h> to provide IO accessors which work on both > AVR32 and ARM for on-chip peripherals. > > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> > -- > CC: Nicolas Ferre <nicolas.ferre@atmel.com> (supporter:ATMEL SPI DRIVER) > CC: Mark Brown <broonie@kernel.org> (maintainer:SPI SUBSYSTEM) > CC: linux-spi@vger.kernel.org (open list:SPI SUBSYSTEM) > CC: linux-arm-kernel@lists.infradead.org > --- > drivers/spi/spi-atmel.c | 13 ++++--------- > 1 file changed, 4 insertions(+), 9 deletions(-) <snipp diff>
On Thu, Mar 26, 2015 at 11:45:52AM +0000, Ben Dooks wrote: > Use <linux/atmel_io.h> to provide IO accessors which work on both > AVR32 and ARM for on-chip peripherals. To repeat the feedback on your previous big endian fix: I've not been CCed on the cover letter or any of the other patches so can someone tell me if there are any dependencies or anything?
Le 26/03/2015 16:38, Mark Brown a écrit : > On Thu, Mar 26, 2015 at 11:45:52AM +0000, Ben Dooks wrote: >> Use <linux/atmel_io.h> to provide IO accessors which work on both >> AVR32 and ARM for on-chip peripherals. > > To repeat the feedback on your previous big endian fix: I've not been > CCed on the cover letter or any of the other patches so can someone tell > me if there are any dependencies or anything? Yes, there is dependency on a common header file. So I think we should keep the series grouped or plan a migration path. Bye,
On Thu, Mar 26, 2015 at 04:41:29PM +0100, Nicolas Ferre wrote: > Le 26/03/2015 16:38, Mark Brown a écrit : > > To repeat the feedback on your previous big endian fix: I've not been > > CCed on the cover letter or any of the other patches so can someone tell > > me if there are any dependencies or anything? > Yes, there is dependency on a common header file. So I think we should > keep the series grouped or plan a migration path. OK, thanks for letting me know - Ben, if you're working on this stuff *please* bear dependency issues like this in mind.
On Thu, Mar 26, 2015 at 11:45:52AM +0000, Ben Dooks wrote: > Use <linux/atmel_io.h> to provide IO accessors which work on both > AVR32 and ARM for on-chip peripherals. Acked-by: Mark Brown <broonie@kernel.org>
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index a2f40b1..f10cc75 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -25,6 +25,7 @@ #include <linux/io.h> #include <linux/gpio.h> +#include <linux/atmel_io.h> #include <linux/pinctrl/consumer.h> #include <linux/pm_runtime.h> @@ -180,17 +181,11 @@ | SPI_BF(name, value)) /* Register access macros */ -#ifdef CONFIG_AVR32 #define spi_readl(port, reg) \ - __raw_readl((port)->regs + SPI_##reg) + atmel_oc_readl((port)->regs + SPI_##reg) #define spi_writel(port, reg, value) \ - __raw_writel((value), (port)->regs + SPI_##reg) -#else -#define spi_readl(port, reg) \ - readl_relaxed((port)->regs + SPI_##reg) -#define spi_writel(port, reg, value) \ - writel_relaxed((value), (port)->regs + SPI_##reg) -#endif + atmel_oc_writel((value), (port)->regs + SPI_##reg) + /* use PIO for small transfers, avoiding DMA setup/teardown overhead and * cache operations; better heuristics consider wordsize and bitrate. */
Use <linux/atmel_io.h> to provide IO accessors which work on both AVR32 and ARM for on-chip peripherals. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> -- CC: Nicolas Ferre <nicolas.ferre@atmel.com> (supporter:ATMEL SPI DRIVER) CC: Mark Brown <broonie@kernel.org> (maintainer:SPI SUBSYSTEM) CC: linux-spi@vger.kernel.org (open list:SPI SUBSYSTEM) CC: linux-arm-kernel@lists.infradead.org --- drivers/spi/spi-atmel.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-)