* [PATCH 2/7] dma: iop-adma: include prefetch.h
[not found] ` <20190809163334.489360-1-arnd@arndb.de>
@ 2019-08-09 16:33 ` Arnd Bergmann
2019-08-13 4:33 ` Vinod Koul
2019-08-09 16:33 ` [PATCH 3/7] dma: iop-adma: use correct printk format strings Arnd Bergmann
` (6 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: Arnd Bergmann @ 2019-08-09 16:33 UTC (permalink / raw)
To: soc
Cc: kbuild test robot, Arnd Bergmann, linux-gpio, Linus Walleij,
Russell King, linux-kernel, Bartosz Golaszewski, Vinod Koul,
linux-i2c, dmaengine, Dan Williams, linux-arm-kernel
Compile-testing this driver fails on m68k without the
extra header inclusion.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/dma/iop-adma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index c6c0143670d9..7857b54770d1 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -16,6 +16,7 @@
#include <linux/spinlock.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
+#include <linux/prefetch.h>
#include <linux/memory.h>
#include <linux/ioport.h>
#include <linux/raid/pq.h>
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH 2/7] dma: iop-adma: include prefetch.h
2019-08-09 16:33 ` [PATCH 2/7] dma: iop-adma: include prefetch.h Arnd Bergmann
@ 2019-08-13 4:33 ` Vinod Koul
2019-08-14 15:29 ` Arnd Bergmann
0 siblings, 1 reply; 23+ messages in thread
From: Vinod Koul @ 2019-08-13 4:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kbuild test robot, linux-gpio, Linus Walleij, Russell King,
linux-kernel, Bartosz Golaszewski, soc, linux-i2c, dmaengine,
Dan Williams, linux-arm-kernel
On 09-08-19, 18:33, Arnd Bergmann wrote:
> Compile-testing this driver fails on m68k without the
> extra header inclusion.
Please change title to "dmaengine: iop-adma: include prefetch.h"
After that:
Acked-by: Vinod Koul <vkoul@kernel.org>
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/dma/iop-adma.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
> index c6c0143670d9..7857b54770d1 100644
> --- a/drivers/dma/iop-adma.c
> +++ b/drivers/dma/iop-adma.c
> @@ -16,6 +16,7 @@
> #include <linux/spinlock.h>
> #include <linux/interrupt.h>
> #include <linux/platform_device.h>
> +#include <linux/prefetch.h>
> #include <linux/memory.h>
> #include <linux/ioport.h>
> #include <linux/raid/pq.h>
> --
> 2.20.0
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/7] dma: iop-adma: include prefetch.h
2019-08-13 4:33 ` Vinod Koul
@ 2019-08-14 15:29 ` Arnd Bergmann
0 siblings, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-08-14 15:29 UTC (permalink / raw)
To: Vinod Koul
Cc: kbuild test robot, open list:GPIO SUBSYSTEM, Linus Walleij,
Russell King, Linux Kernel Mailing List, Bartosz Golaszewski,
soc, Linux I2C, dmaengine, Dan Williams, Linux ARM
On Tue, Aug 13, 2019 at 6:34 AM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 09-08-19, 18:33, Arnd Bergmann wrote:
> > Compile-testing this driver fails on m68k without the
> > extra header inclusion.
>
> Please change title to "dmaengine: iop-adma: include prefetch.h"
>
> After that:
>
> Acked-by: Vinod Koul <vkoul@kernel.org>
Ok, thanks!
One day I will remember all the subsystem prefixes. ;-)
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 3/7] dma: iop-adma: use correct printk format strings
[not found] ` <20190809163334.489360-1-arnd@arndb.de>
2019-08-09 16:33 ` [PATCH 2/7] dma: iop-adma: include prefetch.h Arnd Bergmann
@ 2019-08-09 16:33 ` Arnd Bergmann
2019-08-13 4:33 ` Vinod Koul
2019-08-09 16:33 ` [PATCH 4/7] dma: iop-adma: allow building without platform headers Arnd Bergmann
` (5 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: Arnd Bergmann @ 2019-08-09 16:33 UTC (permalink / raw)
To: soc
Cc: Arnd Bergmann, linux-gpio, Linus Walleij, Russell King,
linux-kernel, Bartosz Golaszewski, Vinod Koul, linux-i2c,
dmaengine, Dan Williams, linux-arm-kernel
When compile-testing on other architectures, we get lots of warnings
about incorrect format strings, like:
drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots':
drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy':
>> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=]
Use %zu for printing size_t as required, and cast the dma_addr_t
arguments to 'u64' for printing with %llx. Ideally this should use
the %pad format string, but that requires an lvalue argument that
doesn't work here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/dma/iop-adma.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index 7857b54770d1..aebdd671651a 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -117,9 +117,9 @@ static void __iop_adma_slot_cleanup(struct iop_adma_chan *iop_chan)
list_for_each_entry_safe(iter, _iter, &iop_chan->chain,
chain_node) {
pr_debug("\tcookie: %d slot: %d busy: %d "
- "this_desc: %#x next_desc: %#x ack: %d\n",
+ "this_desc: %#x next_desc: %#llx ack: %d\n",
iter->async_tx.cookie, iter->idx, busy,
- iter->async_tx.phys, iop_desc_get_next_desc(iter),
+ iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter),
async_tx_test_ack(&iter->async_tx));
prefetch(_iter);
prefetch(&_iter->async_tx);
@@ -307,9 +307,9 @@ iop_adma_alloc_slots(struct iop_adma_chan *iop_chan, int num_slots,
int i;
dev_dbg(iop_chan->device->common.dev,
"allocated slot: %d "
- "(desc %p phys: %#x) slots_per_op %d\n",
+ "(desc %p phys: %#llx) slots_per_op %d\n",
iter->idx, iter->hw_desc,
- iter->async_tx.phys, slots_per_op);
+ (u64)iter->async_tx.phys, slots_per_op);
/* pre-ack all but the last descriptor */
if (num_slots != slots_per_op)
@@ -517,7 +517,7 @@ iop_adma_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dma_dest,
return NULL;
BUG_ON(len > IOP_ADMA_MAX_BYTE_COUNT);
- dev_dbg(iop_chan->device->common.dev, "%s len: %u\n",
+ dev_dbg(iop_chan->device->common.dev, "%s len: %zu\n",
__func__, len);
spin_lock_bh(&iop_chan->lock);
@@ -550,7 +550,7 @@ iop_adma_prep_dma_xor(struct dma_chan *chan, dma_addr_t dma_dest,
BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
dev_dbg(iop_chan->device->common.dev,
- "%s src_cnt: %d len: %u flags: %lx\n",
+ "%s src_cnt: %d len: %zu flags: %lx\n",
__func__, src_cnt, len, flags);
spin_lock_bh(&iop_chan->lock);
@@ -583,7 +583,7 @@ iop_adma_prep_dma_xor_val(struct dma_chan *chan, dma_addr_t *dma_src,
if (unlikely(!len))
return NULL;
- dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n",
+ dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n",
__func__, src_cnt, len);
spin_lock_bh(&iop_chan->lock);
@@ -621,7 +621,7 @@ iop_adma_prep_dma_pq(struct dma_chan *chan, dma_addr_t *dst, dma_addr_t *src,
BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
dev_dbg(iop_chan->device->common.dev,
- "%s src_cnt: %d len: %u flags: %lx\n",
+ "%s src_cnt: %d len: %zu flags: %lx\n",
__func__, src_cnt, len, flags);
if (dmaf_p_disabled_continue(flags))
@@ -684,7 +684,7 @@ iop_adma_prep_dma_pq_val(struct dma_chan *chan, dma_addr_t *pq, dma_addr_t *src,
return NULL;
BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
- dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n",
+ dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n",
__func__, src_cnt, len);
spin_lock_bh(&iop_chan->lock);
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH 3/7] dma: iop-adma: use correct printk format strings
2019-08-09 16:33 ` [PATCH 3/7] dma: iop-adma: use correct printk format strings Arnd Bergmann
@ 2019-08-13 4:33 ` Vinod Koul
0 siblings, 0 replies; 23+ messages in thread
From: Vinod Koul @ 2019-08-13 4:33 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Linus Walleij, Russell King, linux-kernel,
Bartosz Golaszewski, soc, linux-i2c, dmaengine, Dan Williams,
linux-arm-kernel
On 09-08-19, 18:33, Arnd Bergmann wrote:
> When compile-testing on other architectures, we get lots of warnings
> about incorrect format strings, like:
>
> drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots':
> drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
>
> drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy':
> >> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=]
>
> Use %zu for printing size_t as required, and cast the dma_addr_t
> arguments to 'u64' for printing with %llx. Ideally this should use
> the %pad format string, but that requires an lvalue argument that
> doesn't work here.
Please change title to "dmaengine: iop-adma: use correct printk format strings"
After that:
Acked-by: Vinod Koul <vkoul@kernel.org>
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/dma/iop-adma.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
> index 7857b54770d1..aebdd671651a 100644
> --- a/drivers/dma/iop-adma.c
> +++ b/drivers/dma/iop-adma.c
> @@ -117,9 +117,9 @@ static void __iop_adma_slot_cleanup(struct iop_adma_chan *iop_chan)
> list_for_each_entry_safe(iter, _iter, &iop_chan->chain,
> chain_node) {
> pr_debug("\tcookie: %d slot: %d busy: %d "
> - "this_desc: %#x next_desc: %#x ack: %d\n",
> + "this_desc: %#x next_desc: %#llx ack: %d\n",
> iter->async_tx.cookie, iter->idx, busy,
> - iter->async_tx.phys, iop_desc_get_next_desc(iter),
> + iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter),
> async_tx_test_ack(&iter->async_tx));
> prefetch(_iter);
> prefetch(&_iter->async_tx);
> @@ -307,9 +307,9 @@ iop_adma_alloc_slots(struct iop_adma_chan *iop_chan, int num_slots,
> int i;
> dev_dbg(iop_chan->device->common.dev,
> "allocated slot: %d "
> - "(desc %p phys: %#x) slots_per_op %d\n",
> + "(desc %p phys: %#llx) slots_per_op %d\n",
> iter->idx, iter->hw_desc,
> - iter->async_tx.phys, slots_per_op);
> + (u64)iter->async_tx.phys, slots_per_op);
>
> /* pre-ack all but the last descriptor */
> if (num_slots != slots_per_op)
> @@ -517,7 +517,7 @@ iop_adma_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dma_dest,
> return NULL;
> BUG_ON(len > IOP_ADMA_MAX_BYTE_COUNT);
>
> - dev_dbg(iop_chan->device->common.dev, "%s len: %u\n",
> + dev_dbg(iop_chan->device->common.dev, "%s len: %zu\n",
> __func__, len);
>
> spin_lock_bh(&iop_chan->lock);
> @@ -550,7 +550,7 @@ iop_adma_prep_dma_xor(struct dma_chan *chan, dma_addr_t dma_dest,
> BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
>
> dev_dbg(iop_chan->device->common.dev,
> - "%s src_cnt: %d len: %u flags: %lx\n",
> + "%s src_cnt: %d len: %zu flags: %lx\n",
> __func__, src_cnt, len, flags);
>
> spin_lock_bh(&iop_chan->lock);
> @@ -583,7 +583,7 @@ iop_adma_prep_dma_xor_val(struct dma_chan *chan, dma_addr_t *dma_src,
> if (unlikely(!len))
> return NULL;
>
> - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n",
> + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n",
> __func__, src_cnt, len);
>
> spin_lock_bh(&iop_chan->lock);
> @@ -621,7 +621,7 @@ iop_adma_prep_dma_pq(struct dma_chan *chan, dma_addr_t *dst, dma_addr_t *src,
> BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
>
> dev_dbg(iop_chan->device->common.dev,
> - "%s src_cnt: %d len: %u flags: %lx\n",
> + "%s src_cnt: %d len: %zu flags: %lx\n",
> __func__, src_cnt, len, flags);
>
> if (dmaf_p_disabled_continue(flags))
> @@ -684,7 +684,7 @@ iop_adma_prep_dma_pq_val(struct dma_chan *chan, dma_addr_t *pq, dma_addr_t *src,
> return NULL;
> BUG_ON(len > IOP_ADMA_XOR_MAX_BYTE_COUNT);
>
> - dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %u\n",
> + dev_dbg(iop_chan->device->common.dev, "%s src_cnt: %d len: %zu\n",
> __func__, src_cnt, len);
>
> spin_lock_bh(&iop_chan->lock);
> --
> 2.20.0
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 4/7] dma: iop-adma: allow building without platform headers
[not found] ` <20190809163334.489360-1-arnd@arndb.de>
2019-08-09 16:33 ` [PATCH 2/7] dma: iop-adma: include prefetch.h Arnd Bergmann
2019-08-09 16:33 ` [PATCH 3/7] dma: iop-adma: use correct printk format strings Arnd Bergmann
@ 2019-08-09 16:33 ` Arnd Bergmann
2019-08-09 16:33 ` [PATCH 5/7] ARM: xscale: fix multi-cpu compilation Arnd Bergmann
` (4 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-08-09 16:33 UTC (permalink / raw)
To: soc
Cc: Arnd Bergmann, linux-gpio, Linus Walleij, Russell King,
linux-kernel, Bartosz Golaszewski, Vinod Koul, linux-i2c,
dmaengine, Dan Williams, linux-arm-kernel
Now that iop3xx and iop13xx are gone, the iop-adma driver no
longer needs to deal with incompatible register layout defined
in machine specific header files.
Move the iop32x specific definitions into drivers/dma/iop-adma.h
and the platform_data into include/linux/platform_data/dma-iop32x.h,
and change the machine code to no longer reference those.
The DMA0_ID/DMA1_ID/AAU_ID macros are required as part of the
platform data interface and still need to be visible, so move
those from one header to the other.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-iop32x/include/mach/adma.h | 6 ------
arch/arm/plat-iop/adma.c | 3 +--
drivers/dma/Kconfig | 4 ++--
drivers/dma/iop-adma.c | 3 +--
.../asm/hardware/iop3xx-adma.h => drivers/dma/iop-adma.h | 7 +------
.../iop_adma.h => include/linux/platform_data/dma-iop32x.h | 4 ++++
6 files changed, 9 insertions(+), 18 deletions(-)
delete mode 100644 arch/arm/mach-iop32x/include/mach/adma.h
rename arch/arm/include/asm/hardware/iop3xx-adma.h => drivers/dma/iop-adma.h (99%)
rename arch/arm/include/asm/hardware/iop_adma.h => include/linux/platform_data/dma-iop32x.h (98%)
diff --git a/arch/arm/mach-iop32x/include/mach/adma.h b/arch/arm/mach-iop32x/include/mach/adma.h
deleted file mode 100644
index 2b20063123ad..000000000000
--- a/arch/arm/mach-iop32x/include/mach/adma.h
+++ /dev/null
@@ -1,6 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef IOP32X_ADMA_H
-#define IOP32X_ADMA_H
-#include <asm/hardware/iop3xx-adma.h>
-#endif
-
diff --git a/arch/arm/plat-iop/adma.c b/arch/arm/plat-iop/adma.c
index 368496471e60..601cc9c11b07 100644
--- a/arch/arm/plat-iop/adma.c
+++ b/arch/arm/plat-iop/adma.c
@@ -6,8 +6,7 @@
#include <linux/platform_device.h>
#include <asm/hardware/iop3xx.h>
#include <linux/dma-mapping.h>
-#include <mach/adma.h>
-#include <asm/hardware/iop_adma.h>
+#include <linux/platform_data/dma-iop32x.h>
#define IRQ_DMA0_EOT IRQ_IOP32X_DMA0_EOT
#define IRQ_DMA0_EOC IRQ_IOP32X_DMA0_EOC
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index cc84863bc52b..7c511e3db4c8 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -294,8 +294,8 @@ config INTEL_IOATDMA
If unsure, say N.
config INTEL_IOP_ADMA
- tristate "Intel IOP ADMA support"
- depends on ARCH_IOP32X
+ tristate "Intel IOP32x ADMA support"
+ depends on ARCH_IOP32X || COMPILE_TEST
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
help
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index aebdd671651a..03f4a588cf7f 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -22,8 +22,7 @@
#include <linux/raid/pq.h>
#include <linux/slab.h>
-#include <mach/adma.h>
-
+#include "iop-adma.h"
#include "dmaengine.h"
#define to_iop_adma_chan(chan) container_of(chan, struct iop_adma_chan, common)
diff --git a/arch/arm/include/asm/hardware/iop3xx-adma.h b/drivers/dma/iop-adma.h
similarity index 99%
rename from arch/arm/include/asm/hardware/iop3xx-adma.h
rename to drivers/dma/iop-adma.h
index 6d998df17efd..c499c9578f00 100644
--- a/arch/arm/include/asm/hardware/iop3xx-adma.h
+++ b/drivers/dma/iop-adma.h
@@ -6,8 +6,7 @@
#define _ADMA_H
#include <linux/types.h>
#include <linux/io.h>
-#include <mach/hardware.h>
-#include <asm/hardware/iop_adma.h>
+#include <linux/platform_data/dma-iop32x.h>
/* Memory copy units */
#define DMA_CCR(chan) (chan->mmr_base + 0x0)
@@ -34,10 +33,6 @@
#define AAU_EDCR1_IDX 17
#define AAU_EDCR2_IDX 26
-#define DMA0_ID 0
-#define DMA1_ID 1
-#define AAU_ID 2
-
struct iop3xx_aau_desc_ctrl {
unsigned int int_en:1;
unsigned int blk1_cmd_ctrl:3;
diff --git a/arch/arm/include/asm/hardware/iop_adma.h b/include/linux/platform_data/dma-iop32x.h
similarity index 98%
rename from arch/arm/include/asm/hardware/iop_adma.h
rename to include/linux/platform_data/dma-iop32x.h
index bcedbab90ac0..ac83cff89549 100644
--- a/arch/arm/include/asm/hardware/iop_adma.h
+++ b/include/linux/platform_data/dma-iop32x.h
@@ -17,6 +17,10 @@
#endif
#define iop_paranoia(x) BUG_ON(IOP_PARANOIA && (x))
+#define DMA0_ID 0
+#define DMA1_ID 1
+#define AAU_ID 2
+
/**
* struct iop_adma_device - internal representation of an ADMA device
* @pdev: Platform device
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH 5/7] ARM: xscale: fix multi-cpu compilation
[not found] ` <20190809163334.489360-1-arnd@arndb.de>
` (2 preceding siblings ...)
2019-08-09 16:33 ` [PATCH 4/7] dma: iop-adma: allow building without platform headers Arnd Bergmann
@ 2019-08-09 16:33 ` Arnd Bergmann
2019-08-23 7:44 ` Linus Walleij
2019-08-09 16:33 ` [PATCH 6/7] ARM: iop32x: make mach/uncompress.h independent of mach/hardware.h Arnd Bergmann
` (3 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: Arnd Bergmann @ 2019-08-09 16:33 UTC (permalink / raw)
To: soc
Cc: Arnd Bergmann, linux-gpio, Linus Walleij, Russell King,
linux-kernel, Bartosz Golaszewski, Vinod Koul, linux-i2c,
dmaengine, Dan Williams, linux-arm-kernel
Building a combined ARMv4+XScale kernel produces these
and other build failures:
/tmp/copypage-xscale-3aa821.s: Assembler messages:
/tmp/copypage-xscale-3aa821.s:167: Error: selected processor does not support `pld [r7,#0]' in ARM mode
/tmp/copypage-xscale-3aa821.s:168: Error: selected processor does not support `pld [r7,#32]' in ARM mode
/tmp/copypage-xscale-3aa821.s:169: Error: selected processor does not support `pld [r1,#0]' in ARM mode
/tmp/copypage-xscale-3aa821.s:170: Error: selected processor does not support `pld [r1,#32]' in ARM mode
/tmp/copypage-xscale-3aa821.s:171: Error: selected processor does not support `pld [r7,#64]' in ARM mode
/tmp/copypage-xscale-3aa821.s:176: Error: selected processor does not support `ldrd r4,r5,[r7],#8' in ARM mode
/tmp/copypage-xscale-3aa821.s:180: Error: selected processor does not support `strd r4,r5,[r1],#8' in ARM mode
Add an explict .arch armv5 in the inline assembly to allow the ARMv5
specific instructions regardless of the compiler -march= target.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mm/copypage-xscale.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/copypage-xscale.c b/arch/arm/mm/copypage-xscale.c
index 61d834157bc0..382e1c2855e8 100644
--- a/arch/arm/mm/copypage-xscale.c
+++ b/arch/arm/mm/copypage-xscale.c
@@ -42,6 +42,7 @@ static void mc_copy_user_page(void *from, void *to)
* when prefetching destination as well. (NP)
*/
asm volatile ("\
+.arch xscale \n\
pld [%0, #0] \n\
pld [%0, #32] \n\
pld [%1, #0] \n\
@@ -106,8 +107,9 @@ void
xscale_mc_clear_user_highpage(struct page *page, unsigned long vaddr)
{
void *ptr, *kaddr = kmap_atomic(page);
- asm volatile(
- "mov r1, %2 \n\
+ asm volatile("\
+.arch xscale \n\
+ mov r1, %2 \n\
mov r2, #0 \n\
mov r3, #0 \n\
1: mov ip, %0 \n\
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH 5/7] ARM: xscale: fix multi-cpu compilation
2019-08-09 16:33 ` [PATCH 5/7] ARM: xscale: fix multi-cpu compilation Arnd Bergmann
@ 2019-08-23 7:44 ` Linus Walleij
0 siblings, 0 replies; 23+ messages in thread
From: Linus Walleij @ 2019-08-23 7:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: open list:GPIO SUBSYSTEM, linux-kernel, soc, Russell King,
Bartosz Golaszewski, Vinod Koul, linux-i2c, dmaengine,
Dan Williams, Linux ARM
On Fri, Aug 9, 2019 at 6:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
> Building a combined ARMv4+XScale kernel produces these
> and other build failures:
>
> /tmp/copypage-xscale-3aa821.s: Assembler messages:
> /tmp/copypage-xscale-3aa821.s:167: Error: selected processor does not support `pld [r7,#0]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:168: Error: selected processor does not support `pld [r7,#32]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:169: Error: selected processor does not support `pld [r1,#0]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:170: Error: selected processor does not support `pld [r1,#32]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:171: Error: selected processor does not support `pld [r7,#64]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:176: Error: selected processor does not support `ldrd r4,r5,[r7],#8' in ARM mode
> /tmp/copypage-xscale-3aa821.s:180: Error: selected processor does not support `strd r4,r5,[r1],#8' in ARM mode
OK we certainly need this.
> Add an explict .arch armv5 in the inline assembly to allow the ARMv5
> specific instructions regardless of the compiler -march= target.
You probably mean...
> +.arch xscale \n\
> pld [%0, #0] \n\
Explicit .arch xscale rather than .arch armv5.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 6/7] ARM: iop32x: make mach/uncompress.h independent of mach/hardware.h
[not found] ` <20190809163334.489360-1-arnd@arndb.de>
` (3 preceding siblings ...)
2019-08-09 16:33 ` [PATCH 5/7] ARM: xscale: fix multi-cpu compilation Arnd Bergmann
@ 2019-08-09 16:33 ` Arnd Bergmann
2019-08-09 16:33 ` [PATCH 7/7] ARM: iop32x: merge everything into mach-iop32x/ Arnd Bergmann
` (2 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-08-09 16:33 UTC (permalink / raw)
To: soc
Cc: Arnd Bergmann, linux-gpio, Linus Walleij, Russell King,
linux-kernel, Bartosz Golaszewski, Vinod Koul, linux-i2c,
dmaengine, Dan Williams, linux-arm-kernel
All supported uarts use the same address: IQ80321_UART and IQ31244_UART
are both defined to the default value of 0xfe800000. By using that as
the address unconditionally, all dependencies on other machine headers
can be avoided.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-iop32x/include/mach/uncompress.h | 18 ++----------------
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-iop32x/include/mach/uncompress.h b/arch/arm/mach-iop32x/include/mach/uncompress.h
index ed4ac3e28fa1..c8548875d942 100644
--- a/arch/arm/mach-iop32x/include/mach/uncompress.h
+++ b/arch/arm/mach-iop32x/include/mach/uncompress.h
@@ -6,9 +6,8 @@
#include <asm/types.h>
#include <asm/mach-types.h>
#include <linux/serial_reg.h>
-#include <mach/hardware.h>
-volatile u8 *uart_base;
+#define uart_base ((volatile u8 *)0xfe800000)
#define TX_DONE (UART_LSR_TEMT | UART_LSR_THRE)
@@ -23,17 +22,4 @@ static inline void flush(void)
{
}
-static __inline__ void __arch_decomp_setup(unsigned long arch_id)
-{
- if (machine_is_iq80321())
- uart_base = (volatile u8 *)IQ80321_UART;
- else if (machine_is_iq31244() || machine_is_em7210())
- uart_base = (volatile u8 *)IQ31244_UART;
- else
- uart_base = (volatile u8 *)0xfe800000;
-}
-
-/*
- * nothing to do
- */
-#define arch_decomp_setup() __arch_decomp_setup(arch_id)
+#define arch_decomp_setup() do { } while (0)
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH 7/7] ARM: iop32x: merge everything into mach-iop32x/
[not found] ` <20190809163334.489360-1-arnd@arndb.de>
` (4 preceding siblings ...)
2019-08-09 16:33 ` [PATCH 6/7] ARM: iop32x: make mach/uncompress.h independent of mach/hardware.h Arnd Bergmann
@ 2019-08-09 16:33 ` Arnd Bergmann
2019-08-09 16:57 ` [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support Wolfram Sang
2019-08-09 18:34 ` Dan Williams
7 siblings, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-08-09 16:33 UTC (permalink / raw)
To: soc
Cc: Arnd Bergmann, linux-gpio, Linus Walleij, Russell King,
linux-kernel, Bartosz Golaszewski, Vinod Koul, linux-i2c,
dmaengine, Dan Williams, linux-arm-kernel
Various bits of iop32x are now in their traditional locations in plat-iop,
mach-iop/include/mach/ and in include/asm/mach/hardware. As nothing
outside of the iop32x mach code references these any more, this can all
be moved into one place now.
The only remaining things in the include/mach/ directory are now the
NR_IRQS definition, the entry-macros.S file and the the decompressor
uart access. After the irqchip code has been converted to SPARSE_IRQ
and GENERIC_IRQ_MULTI_HANDLER, it can be moved to ARCH_MULTIPLATFORM.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/Makefile | 1 -
arch/arm/mach-iop32x/Makefile | 10 ++++-
arch/arm/{plat-iop => mach-iop32x}/adma.c | 4 +-
arch/arm/{plat-iop => mach-iop32x}/cp6.c | 0
arch/arm/mach-iop32x/em7210.c | 5 ++-
arch/arm/mach-iop32x/glantank.c | 5 ++-
.../mach-iop32x/{include/mach => }/glantank.h | 2 -
.../mach-iop32x/{include/mach => }/hardware.h | 6 +--
arch/arm/{plat-iop => mach-iop32x}/i2c.c | 6 ++-
.../mach-iop32x/include/mach/entry-macro.S | 2 -
arch/arm/mach-iop32x/include/mach/iop32x.h | 31 --------------
arch/arm/mach-iop32x/include/mach/irqs.h | 33 ---------------
arch/arm/mach-iop32x/include/mach/time.h | 5 ---
.../asm/hardware => mach-iop32x}/iop3xx.h | 18 +++++++-
arch/arm/mach-iop32x/iq31244.c | 5 ++-
.../mach-iop32x/{include/mach => }/iq31244.h | 2 -
arch/arm/mach-iop32x/iq80321.c | 5 ++-
.../mach-iop32x/{include/mach => }/iq80321.h | 2 -
arch/arm/mach-iop32x/irq.c | 3 +-
arch/arm/mach-iop32x/irqs.h | 42 +++++++++++++++++++
arch/arm/mach-iop32x/n2100.c | 5 ++-
.../mach-iop32x/{include/mach => }/n2100.h | 2 -
arch/arm/{plat-iop => mach-iop32x}/pci.c | 4 +-
arch/arm/{plat-iop => mach-iop32x}/pmu.c | 2 +-
arch/arm/{plat-iop => mach-iop32x}/restart.c | 4 +-
arch/arm/{plat-iop => mach-iop32x}/setup.c | 2 +-
arch/arm/{plat-iop => mach-iop32x}/time.c | 7 ++--
arch/arm/plat-iop/Makefile | 14 -------
28 files changed, 102 insertions(+), 125 deletions(-)
rename arch/arm/{plat-iop => mach-iop32x}/adma.c (98%)
rename arch/arm/{plat-iop => mach-iop32x}/cp6.c (100%)
rename arch/arm/mach-iop32x/{include/mach => }/glantank.h (78%)
rename arch/arm/mach-iop32x/{include/mach => }/hardware.h (90%)
rename arch/arm/{plat-iop => mach-iop32x}/i2c.c (96%)
delete mode 100644 arch/arm/mach-iop32x/include/mach/iop32x.h
delete mode 100644 arch/arm/mach-iop32x/include/mach/time.h
rename arch/arm/{include/asm/hardware => mach-iop32x}/iop3xx.h (96%)
rename arch/arm/mach-iop32x/{include/mach => }/iq31244.h (89%)
rename arch/arm/mach-iop32x/{include/mach => }/iq80321.h (89%)
create mode 100644 arch/arm/mach-iop32x/irqs.h
rename arch/arm/mach-iop32x/{include/mach => }/n2100.h (89%)
rename arch/arm/{plat-iop => mach-iop32x}/pci.c (99%)
rename arch/arm/{plat-iop => mach-iop32x}/pmu.c (96%)
rename arch/arm/{plat-iop => mach-iop32x}/restart.c (82%)
rename arch/arm/{plat-iop => mach-iop32x}/setup.c (95%)
rename arch/arm/{plat-iop => mach-iop32x}/time.c (97%)
delete mode 100644 arch/arm/plat-iop/Makefile
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d92bc5328df7..075dd2f06d78 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -231,7 +231,6 @@ plat-$(CONFIG_ARCH_EXYNOS) += samsung
plat-$(CONFIG_ARCH_OMAP) += omap
plat-$(CONFIG_ARCH_S3C64XX) += samsung
plat-$(CONFIG_ARCH_S5PV210) += samsung
-plat-$(CONFIG_PLAT_IOP) += iop
plat-$(CONFIG_PLAT_ORION) += orion
plat-$(CONFIG_PLAT_PXA) += pxa
plat-$(CONFIG_PLAT_S3C24XX) += samsung
diff --git a/arch/arm/mach-iop32x/Makefile b/arch/arm/mach-iop32x/Makefile
index 71d62447d4d5..c8018ef5c6a9 100644
--- a/arch/arm/mach-iop32x/Makefile
+++ b/arch/arm/mach-iop32x/Makefile
@@ -3,7 +3,15 @@
# Makefile for the linux kernel.
#
-obj-y := irq.o
+obj-$(CONFIG_ARCH_IOP32X) += irq.o
+obj-$(CONFIG_ARCH_IOP32X) += i2c.o
+obj-$(CONFIG_ARCH_IOP32X) += pci.o
+obj-$(CONFIG_ARCH_IOP32X) += setup.o
+obj-$(CONFIG_ARCH_IOP32X) += time.o
+obj-$(CONFIG_ARCH_IOP32X) += cp6.o
+obj-$(CONFIG_ARCH_IOP32X) += adma.o
+obj-$(CONFIG_ARCH_IOP32X) += pmu.o
+obj-$(CONFIG_ARCH_IOP32X) += restart.o
obj-$(CONFIG_MACH_GLANTANK) += glantank.o
obj-$(CONFIG_ARCH_IQ80321) += iq80321.o
diff --git a/arch/arm/plat-iop/adma.c b/arch/arm/mach-iop32x/adma.c
similarity index 98%
rename from arch/arm/plat-iop/adma.c
rename to arch/arm/mach-iop32x/adma.c
index 601cc9c11b07..764bcbff98df 100644
--- a/arch/arm/plat-iop/adma.c
+++ b/arch/arm/mach-iop32x/adma.c
@@ -4,10 +4,12 @@
* Copyright © 2006, Intel Corporation.
*/
#include <linux/platform_device.h>
-#include <asm/hardware/iop3xx.h>
#include <linux/dma-mapping.h>
#include <linux/platform_data/dma-iop32x.h>
+#include "iop3xx.h"
+#include "irqs.h"
+
#define IRQ_DMA0_EOT IRQ_IOP32X_DMA0_EOT
#define IRQ_DMA0_EOC IRQ_IOP32X_DMA0_EOC
#define IRQ_DMA0_ERR IRQ_IOP32X_DMA0_ERR
diff --git a/arch/arm/plat-iop/cp6.c b/arch/arm/mach-iop32x/cp6.c
similarity index 100%
rename from arch/arm/plat-iop/cp6.c
rename to arch/arm/mach-iop32x/cp6.c
diff --git a/arch/arm/mach-iop32x/em7210.c b/arch/arm/mach-iop32x/em7210.c
index 61a1e593f9ec..d43ced3cd4e7 100644
--- a/arch/arm/mach-iop32x/em7210.c
+++ b/arch/arm/mach-iop32x/em7210.c
@@ -21,7 +21,6 @@
#include <linux/i2c.h>
#include <linux/gpio.h>
#include <linux/gpio/machine.h>
-#include <mach/hardware.h>
#include <linux/io.h>
#include <linux/irq.h>
#include <asm/mach/arch.h>
@@ -29,8 +28,10 @@
#include <asm/mach/pci.h>
#include <asm/mach/time.h>
#include <asm/mach-types.h>
-#include <mach/time.h>
+
+#include "hardware.h"
#include "gpio-iop32x.h"
+#include "irqs.h"
static void __init em7210_timer_init(void)
{
diff --git a/arch/arm/mach-iop32x/glantank.c b/arch/arm/mach-iop32x/glantank.c
index 5a45d616d9ac..2fe0f77d1f1d 100644
--- a/arch/arm/mach-iop32x/glantank.c
+++ b/arch/arm/mach-iop32x/glantank.c
@@ -22,7 +22,6 @@
#include <linux/platform_device.h>
#include <linux/io.h>
#include <linux/gpio/machine.h>
-#include <mach/hardware.h>
#include <asm/irq.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -30,8 +29,10 @@
#include <asm/mach/time.h>
#include <asm/mach-types.h>
#include <asm/page.h>
-#include <mach/time.h>
+
+#include "hardware.h"
#include "gpio-iop32x.h"
+#include "irqs.h"
/*
* GLAN Tank timer tick configuration.
diff --git a/arch/arm/mach-iop32x/include/mach/glantank.h b/arch/arm/mach-iop32x/glantank.h
similarity index 78%
rename from arch/arm/mach-iop32x/include/mach/glantank.h
rename to arch/arm/mach-iop32x/glantank.h
index b9df2e4614cf..f38e86b82c3d 100644
--- a/arch/arm/mach-iop32x/include/mach/glantank.h
+++ b/arch/arm/mach-iop32x/glantank.h
@@ -1,7 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * arch/arm/mach-iop32x/include/mach/glantank.h
- *
* IO-Data GLAN Tank board registers
*/
diff --git a/arch/arm/mach-iop32x/include/mach/hardware.h b/arch/arm/mach-iop32x/hardware.h
similarity index 90%
rename from arch/arm/mach-iop32x/include/mach/hardware.h
rename to arch/arm/mach-iop32x/hardware.h
index 6e5303e60226..43ab4fb8f9b0 100644
--- a/arch/arm/mach-iop32x/include/mach/hardware.h
+++ b/arch/arm/mach-iop32x/hardware.h
@@ -1,8 +1,4 @@
/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * arch/arm/mach-iop32x/include/mach/hardware.h
- */
-
#ifndef __HARDWARE_H
#define __HARDWARE_H
@@ -28,7 +24,7 @@ void iop32x_init_irq(void);
/*
* Generic chipset bits
*/
-#include "iop32x.h"
+#include "iop3xx.h"
/*
* Board specific bits
diff --git a/arch/arm/plat-iop/i2c.c b/arch/arm/mach-iop32x/i2c.c
similarity index 96%
rename from arch/arm/plat-iop/i2c.c
rename to arch/arm/mach-iop32x/i2c.c
index 8d5fe349c7cd..dc9f6a14ab1b 100644
--- a/arch/arm/plat-iop/i2c.c
+++ b/arch/arm/mach-iop32x/i2c.c
@@ -22,10 +22,12 @@
#include <asm/mach/map.h>
#include <asm/setup.h>
#include <asm/memory.h>
-#include <mach/hardware.h>
-#include <asm/hardware/iop3xx.h>
#include <asm/mach/arch.h>
+#include "hardware.h"
+#include "iop3xx.h"
+#include "irqs.h"
+
/*
* Each of the I2C busses have corresponding GPIO lines, and the driver
* need to access these directly to drive the bus low at times.
diff --git a/arch/arm/mach-iop32x/include/mach/entry-macro.S b/arch/arm/mach-iop32x/include/mach/entry-macro.S
index ea13ae02d9b1..8e6766d4621e 100644
--- a/arch/arm/mach-iop32x/include/mach/entry-macro.S
+++ b/arch/arm/mach-iop32x/include/mach/entry-macro.S
@@ -7,8 +7,6 @@
* License version 2. This program is licensed "as is" without any
* warranty of any kind, whether express or implied.
*/
-#include <mach/iop32x.h>
-
.macro get_irqnr_preamble, base, tmp
mrc p15, 0, \tmp, c15, c1, 0
orr \tmp, \tmp, #(1 << 6)
diff --git a/arch/arm/mach-iop32x/include/mach/iop32x.h b/arch/arm/mach-iop32x/include/mach/iop32x.h
deleted file mode 100644
index 84223f86552f..000000000000
--- a/arch/arm/mach-iop32x/include/mach/iop32x.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * arch/arm/mach-iop32x/include/mach/iop32x.h
- *
- * Intel IOP32X Chip definitions
- *
- * Author: Rory Bolt <rorybolt@pacbell.net>
- * Copyright (C) 2002 Rory Bolt
- * Copyright (C) 2004 Intel Corp.
- */
-
-#ifndef __IOP32X_H
-#define __IOP32X_H
-
-/*
- * Peripherals that are shared between the iop32x and iop33x but
- * located at different addresses.
- */
-#define IOP3XX_TIMER_REG(reg) (IOP3XX_PERIPHERAL_VIRT_BASE + 0x07e0 + (reg))
-
-#include <asm/hardware/iop3xx.h>
-
-/* ATU Parameters
- * set up a 1:1 bus to physical ram relationship
- * w/ physical ram on top of pci in the memory map
- */
-#define IOP32X_MAX_RAM_SIZE 0x40000000UL
-#define IOP3XX_MAX_RAM_SIZE IOP32X_MAX_RAM_SIZE
-#define IOP3XX_PCI_LOWER_MEM_BA 0x80000000
-
-#endif
diff --git a/arch/arm/mach-iop32x/include/mach/irqs.h b/arch/arm/mach-iop32x/include/mach/irqs.h
index 82b11743e91c..c4e78df428e8 100644
--- a/arch/arm/mach-iop32x/include/mach/irqs.h
+++ b/arch/arm/mach-iop32x/include/mach/irqs.h
@@ -9,39 +9,6 @@
#ifndef __IRQS_H
#define __IRQS_H
-/*
- * IOP80321 chipset interrupts
- */
-#define IRQ_IOP32X_DMA0_EOT 0
-#define IRQ_IOP32X_DMA0_EOC 1
-#define IRQ_IOP32X_DMA1_EOT 2
-#define IRQ_IOP32X_DMA1_EOC 3
-#define IRQ_IOP32X_AA_EOT 6
-#define IRQ_IOP32X_AA_EOC 7
-#define IRQ_IOP32X_CORE_PMON 8
-#define IRQ_IOP32X_TIMER0 9
-#define IRQ_IOP32X_TIMER1 10
-#define IRQ_IOP32X_I2C_0 11
-#define IRQ_IOP32X_I2C_1 12
-#define IRQ_IOP32X_MESSAGING 13
-#define IRQ_IOP32X_ATU_BIST 14
-#define IRQ_IOP32X_PERFMON 15
-#define IRQ_IOP32X_CORE_PMU 16
-#define IRQ_IOP32X_BIU_ERR 17
-#define IRQ_IOP32X_ATU_ERR 18
-#define IRQ_IOP32X_MCU_ERR 19
-#define IRQ_IOP32X_DMA0_ERR 20
-#define IRQ_IOP32X_DMA1_ERR 21
-#define IRQ_IOP32X_AA_ERR 23
-#define IRQ_IOP32X_MSG_ERR 24
-#define IRQ_IOP32X_SSP 25
-#define IRQ_IOP32X_XINT0 27
-#define IRQ_IOP32X_XINT1 28
-#define IRQ_IOP32X_XINT2 29
-#define IRQ_IOP32X_XINT3 30
-#define IRQ_IOP32X_HPI 31
-
#define NR_IRQS 32
-
#endif
diff --git a/arch/arm/mach-iop32x/include/mach/time.h b/arch/arm/mach-iop32x/include/mach/time.h
deleted file mode 100644
index d08950ccebc4..000000000000
--- a/arch/arm/mach-iop32x/include/mach/time.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _IOP32X_TIME_H_
-#define _IOP32X_TIME_H_
-#define IRQ_IOP_TIMER0 IRQ_IOP32X_TIMER0
-#endif
diff --git a/arch/arm/include/asm/hardware/iop3xx.h b/arch/arm/mach-iop32x/iop3xx.h
similarity index 96%
rename from arch/arm/include/asm/hardware/iop3xx.h
rename to arch/arm/mach-iop32x/iop3xx.h
index 3cb6f22f510b..46b4b34a4ad2 100644
--- a/arch/arm/include/asm/hardware/iop3xx.h
+++ b/arch/arm/mach-iop32x/iop3xx.h
@@ -1,7 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
- * arch/arm/include/asm/hardware/iop3xx.h
- *
* Intel IOP32X and IOP33X register definitions
*
* Author: Rory Bolt <rorybolt@pacbell.net>
@@ -12,6 +10,22 @@
#ifndef __IOP3XX_H
#define __IOP3XX_H
+/*
+ * Peripherals that are shared between the iop32x and iop33x but
+ * located at different addresses.
+ */
+#define IOP3XX_TIMER_REG(reg) (IOP3XX_PERIPHERAL_VIRT_BASE + 0x07e0 + (reg))
+
+#include "iop3xx.h"
+
+/* ATU Parameters
+ * set up a 1:1 bus to physical ram relationship
+ * w/ physical ram on top of pci in the memory map
+ */
+#define IOP32X_MAX_RAM_SIZE 0x40000000UL
+#define IOP3XX_MAX_RAM_SIZE IOP32X_MAX_RAM_SIZE
+#define IOP3XX_PCI_LOWER_MEM_BA 0x80000000
+
/*
* IOP3XX GPIO handling
*/
diff --git a/arch/arm/mach-iop32x/iq31244.c b/arch/arm/mach-iop32x/iq31244.c
index 8755aa87e591..04a7d389d365 100644
--- a/arch/arm/mach-iop32x/iq31244.c
+++ b/arch/arm/mach-iop32x/iq31244.c
@@ -23,7 +23,6 @@
#include <linux/platform_device.h>
#include <linux/io.h>
#include <linux/gpio/machine.h>
-#include <mach/hardware.h>
#include <asm/cputype.h>
#include <asm/irq.h>
#include <asm/mach/arch.h>
@@ -33,7 +32,9 @@
#include <asm/mach-types.h>
#include <asm/page.h>
#include <asm/pgtable.h>
-#include <mach/time.h>
+
+#include "hardware.h"
+#include "irqs.h"
#include "gpio-iop32x.h"
/*
diff --git a/arch/arm/mach-iop32x/include/mach/iq31244.h b/arch/arm/mach-iop32x/iq31244.h
similarity index 89%
rename from arch/arm/mach-iop32x/include/mach/iq31244.h
rename to arch/arm/mach-iop32x/iq31244.h
index e62da5da6ed4..a7ac691e48d3 100644
--- a/arch/arm/mach-iop32x/include/mach/iq31244.h
+++ b/arch/arm/mach-iop32x/iq31244.h
@@ -1,7 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * arch/arm/mach-iop32x/include/mach/iq31244.h
- *
* Intel IQ31244 evaluation board registers
*/
diff --git a/arch/arm/mach-iop32x/iq80321.c b/arch/arm/mach-iop32x/iq80321.c
index e12699d1c540..4bd596d6c9c1 100644
--- a/arch/arm/mach-iop32x/iq80321.c
+++ b/arch/arm/mach-iop32x/iq80321.c
@@ -20,7 +20,6 @@
#include <linux/platform_device.h>
#include <linux/io.h>
#include <linux/gpio/machine.h>
-#include <mach/hardware.h>
#include <asm/irq.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -29,7 +28,9 @@
#include <asm/mach-types.h>
#include <asm/page.h>
#include <asm/pgtable.h>
-#include <mach/time.h>
+
+#include "hardware.h"
+#include "irqs.h"
#include "gpio-iop32x.h"
/*
diff --git a/arch/arm/mach-iop32x/include/mach/iq80321.h b/arch/arm/mach-iop32x/iq80321.h
similarity index 89%
rename from arch/arm/mach-iop32x/include/mach/iq80321.h
rename to arch/arm/mach-iop32x/iq80321.h
index faf62c26f6f8..3a5d10626ea6 100644
--- a/arch/arm/mach-iop32x/include/mach/iq80321.h
+++ b/arch/arm/mach-iop32x/iq80321.h
@@ -1,7 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * arch/arm/mach-iop32x/include/mach/iq80321.h
- *
* Intel IQ80321 evaluation board registers
*/
diff --git a/arch/arm/mach-iop32x/irq.c b/arch/arm/mach-iop32x/irq.c
index 2f5d4ec94f9c..2d48bf1398c1 100644
--- a/arch/arm/mach-iop32x/irq.c
+++ b/arch/arm/mach-iop32x/irq.c
@@ -13,9 +13,10 @@
#include <linux/list.h>
#include <asm/mach/irq.h>
#include <asm/irq.h>
-#include <mach/hardware.h>
#include <asm/mach-types.h>
+#include "hardware.h"
+
static u32 iop32x_mask;
static void intctl_write(u32 val)
diff --git a/arch/arm/mach-iop32x/irqs.h b/arch/arm/mach-iop32x/irqs.h
new file mode 100644
index 000000000000..69858e4e905d
--- /dev/null
+++ b/arch/arm/mach-iop32x/irqs.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Author: Rory Bolt <rorybolt@pacbell.net>
+ * Copyright: (C) 2002 Rory Bolt
+ */
+
+#ifndef __IOP32X_IRQS_H
+#define __IOP32X_IRQS_H
+
+/*
+ * IOP80321 chipset interrupts
+ */
+#define IRQ_IOP32X_DMA0_EOT 0
+#define IRQ_IOP32X_DMA0_EOC 1
+#define IRQ_IOP32X_DMA1_EOT 2
+#define IRQ_IOP32X_DMA1_EOC 3
+#define IRQ_IOP32X_AA_EOT 6
+#define IRQ_IOP32X_AA_EOC 7
+#define IRQ_IOP32X_CORE_PMON 8
+#define IRQ_IOP32X_TIMER0 9
+#define IRQ_IOP32X_TIMER1 10
+#define IRQ_IOP32X_I2C_0 11
+#define IRQ_IOP32X_I2C_1 12
+#define IRQ_IOP32X_MESSAGING 13
+#define IRQ_IOP32X_ATU_BIST 14
+#define IRQ_IOP32X_PERFMON 15
+#define IRQ_IOP32X_CORE_PMU 16
+#define IRQ_IOP32X_BIU_ERR 17
+#define IRQ_IOP32X_ATU_ERR 18
+#define IRQ_IOP32X_MCU_ERR 19
+#define IRQ_IOP32X_DMA0_ERR 20
+#define IRQ_IOP32X_DMA1_ERR 21
+#define IRQ_IOP32X_AA_ERR 23
+#define IRQ_IOP32X_MSG_ERR 24
+#define IRQ_IOP32X_SSP 25
+#define IRQ_IOP32X_XINT0 27
+#define IRQ_IOP32X_XINT1 28
+#define IRQ_IOP32X_XINT2 29
+#define IRQ_IOP32X_XINT3 30
+#define IRQ_IOP32X_HPI 31
+
+#endif
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index 26d76b377e79..5382a93ad0f8 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -28,7 +28,6 @@
#include <linux/io.h>
#include <linux/gpio.h>
#include <linux/gpio/machine.h>
-#include <mach/hardware.h>
#include <asm/irq.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -37,7 +36,9 @@
#include <asm/mach-types.h>
#include <asm/page.h>
#include <asm/pgtable.h>
-#include <mach/time.h>
+
+#include "hardware.h"
+#include "irqs.h"
#include "gpio-iop32x.h"
/*
diff --git a/arch/arm/mach-iop32x/include/mach/n2100.h b/arch/arm/mach-iop32x/n2100.h
similarity index 89%
rename from arch/arm/mach-iop32x/include/mach/n2100.h
rename to arch/arm/mach-iop32x/n2100.h
index 70bb660b643a..0b97b940d3e7 100644
--- a/arch/arm/mach-iop32x/include/mach/n2100.h
+++ b/arch/arm/mach-iop32x/n2100.h
@@ -1,7 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * arch/arm/mach-iop32x/include/mach/n2100.h
- *
* Thecus N2100 board registers
*/
diff --git a/arch/arm/plat-iop/pci.c b/arch/arm/mach-iop32x/pci.c
similarity index 99%
rename from arch/arm/plat-iop/pci.c
rename to arch/arm/mach-iop32x/pci.c
index 4c42c95e4bf5..ab0010dc3145 100644
--- a/arch/arm/plat-iop/pci.c
+++ b/arch/arm/mach-iop32x/pci.c
@@ -17,9 +17,9 @@
#include <linux/io.h>
#include <asm/irq.h>
#include <asm/signal.h>
-#include <mach/hardware.h>
#include <asm/mach/pci.h>
-#include <asm/hardware/iop3xx.h>
+#include "hardware.h"
+#include "iop3xx.h"
// #define DEBUG
diff --git a/arch/arm/plat-iop/pmu.c b/arch/arm/mach-iop32x/pmu.c
similarity index 96%
rename from arch/arm/plat-iop/pmu.c
rename to arch/arm/mach-iop32x/pmu.c
index 3834142c17f4..bdbc7a3cb8a3 100644
--- a/arch/arm/plat-iop/pmu.c
+++ b/arch/arm/mach-iop32x/pmu.c
@@ -5,7 +5,7 @@
*/
#include <linux/platform_device.h>
-#include <mach/irqs.h>
+#include "irqs.h"
static struct resource pmu_resource = {
.start = IRQ_IOP32X_CORE_PMU,
diff --git a/arch/arm/plat-iop/restart.c b/arch/arm/mach-iop32x/restart.c
similarity index 82%
rename from arch/arm/plat-iop/restart.c
rename to arch/arm/mach-iop32x/restart.c
index cf6d3d9a2112..3dfa54d3a7a8 100644
--- a/arch/arm/plat-iop/restart.c
+++ b/arch/arm/mach-iop32x/restart.c
@@ -4,9 +4,9 @@
*
* Copyright (C) 2001 MontaVista Software, Inc.
*/
-#include <asm/hardware/iop3xx.h>
#include <asm/system_misc.h>
-#include <mach/hardware.h>
+#include "hardware.h"
+#include "iop3xx.h"
void iop3xx_restart(enum reboot_mode mode, const char *cmd)
{
diff --git a/arch/arm/plat-iop/setup.c b/arch/arm/mach-iop32x/setup.c
similarity index 95%
rename from arch/arm/plat-iop/setup.c
rename to arch/arm/mach-iop32x/setup.c
index d10e0102d82c..a0a81c28a632 100644
--- a/arch/arm/plat-iop/setup.c
+++ b/arch/arm/mach-iop32x/setup.c
@@ -10,7 +10,7 @@
#include <linux/mm.h>
#include <linux/init.h>
#include <asm/mach/map.h>
-#include <asm/hardware/iop3xx.h>
+#include "iop3xx.h"
/*
* Standard IO mapping for all IOP3xx based systems. Note that
diff --git a/arch/arm/plat-iop/time.c b/arch/arm/mach-iop32x/time.c
similarity index 97%
rename from arch/arm/plat-iop/time.c
rename to arch/arm/mach-iop32x/time.c
index f9dd1f50cfe5..18a4df5c1baa 100644
--- a/arch/arm/plat-iop/time.c
+++ b/arch/arm/mach-iop32x/time.c
@@ -19,12 +19,13 @@
#include <linux/clockchips.h>
#include <linux/export.h>
#include <linux/sched_clock.h>
-#include <mach/hardware.h>
#include <asm/irq.h>
#include <linux/uaccess.h>
#include <asm/mach/irq.h>
#include <asm/mach/time.h>
-#include <mach/time.h>
+
+#include "hardware.h"
+#include "irqs.h"
/*
* Minimum clocksource/clockevent timer range in seconds
@@ -167,7 +168,7 @@ void __init iop_init_time(unsigned long tick_rate)
*/
write_tmr0(timer_ctl & ~IOP_TMR_EN);
write_tisr(1);
- setup_irq(IRQ_IOP_TIMER0, &iop_timer_irq);
+ setup_irq(IRQ_IOP32X_TIMER0, &iop_timer_irq);
iop_clockevent.cpumask = cpumask_of(0);
clockevents_config_and_register(&iop_clockevent, tick_rate,
0xf, 0xfffffffe);
diff --git a/arch/arm/plat-iop/Makefile b/arch/arm/plat-iop/Makefile
deleted file mode 100644
index 86e354b9065d..000000000000
--- a/arch/arm/plat-iop/Makefile
+++ /dev/null
@@ -1,14 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-#
-# Makefile for the linux kernel.
-#
-
-# IOP32X
-obj-$(CONFIG_ARCH_IOP32X) += i2c.o
-obj-$(CONFIG_ARCH_IOP32X) += pci.o
-obj-$(CONFIG_ARCH_IOP32X) += setup.o
-obj-$(CONFIG_ARCH_IOP32X) += time.o
-obj-$(CONFIG_ARCH_IOP32X) += cp6.o
-obj-$(CONFIG_ARCH_IOP32X) += adma.o
-obj-$(CONFIG_ARCH_IOP32X) += pmu.o
-obj-$(CONFIG_ARCH_IOP32X) += restart.o
--
2.20.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
[not found] ` <20190809163334.489360-1-arnd@arndb.de>
` (5 preceding siblings ...)
2019-08-09 16:33 ` [PATCH 7/7] ARM: iop32x: merge everything into mach-iop32x/ Arnd Bergmann
@ 2019-08-09 16:57 ` Wolfram Sang
2019-08-09 18:34 ` Dan Williams
7 siblings, 0 replies; 23+ messages in thread
From: Wolfram Sang @ 2019-08-09 16:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, linux-kernel, Linus Walleij, soc, Russell King,
Bartosz Golaszewski, Vinod Koul, linux-i2c, dmaengine,
Dan Williams, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 918 bytes --]
On Fri, Aug 09, 2019 at 06:33:15PM +0200, Arnd Bergmann wrote:
> There are three families of IOP machines we support in Linux: iop32x
> (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x).
>
> All products we support in the kernel are based on the first of these,
> iop32x, the other families only ever supported the Intel reference
> boards but no actual machine anyone could ever buy.
>
> While one could clearly make them all three work in a single kernel
> with some work, this takes the easy way out, removing the later two
> platforms entirely, under the assumption that there are no remaining
> users.
>
> Earlier versions of OpenWRT and Debian both had support for iop32x
> but not the others, and they both dropped iop32x as well in their 2015
> releases.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de> # for I2C parts
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
[not found] ` <20190809163334.489360-1-arnd@arndb.de>
` (6 preceding siblings ...)
2019-08-09 16:57 ` [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support Wolfram Sang
@ 2019-08-09 18:34 ` Dan Williams
2019-08-09 18:36 ` Russell King - ARM Linux admin
2019-08-12 9:44 ` Martin Michlmayr
7 siblings, 2 replies; 23+ messages in thread
From: Dan Williams @ 2019-08-09 18:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Linux Kernel Mailing List, Linus Walleij, soc,
Russell King, Bartosz Golaszewski, Vinod Koul, linux-i2c,
dmaengine, Martin Michlmayr, linux-arm-kernel
[ add Martin (if cyrius.com address is still valid) ]
On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> There are three families of IOP machines we support in Linux: iop32x
> (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x).
>
> All products we support in the kernel are based on the first of these,
> iop32x, the other families only ever supported the Intel reference
> boards but no actual machine anyone could ever buy.
>
> While one could clearly make them all three work in a single kernel
> with some work, this takes the easy way out, removing the later two
> platforms entirely, under the assumption that there are no remaining
> users.
>
> Earlier versions of OpenWRT and Debian both had support for iop32x
> but not the others, and they both dropped iop32x as well in their 2015
> releases.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I'm just guessing that iop32x is still needed, and the other two are
> not. If anyone disagrees with that assessment, let me know so we
> can come up with an alternative approach.
I'm not sure who would scream if iop32x support went away as well, but
I have not followed this space in years hence copying Martin.
In any event:
Acked-by: Dan Williams <dan.j.williams@intel.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
2019-08-09 18:34 ` Dan Williams
@ 2019-08-09 18:36 ` Russell King - ARM Linux admin
2019-08-09 19:43 ` Dan Williams
2019-08-12 9:44 ` Martin Michlmayr
1 sibling, 1 reply; 23+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-09 18:36 UTC (permalink / raw)
To: Dan Williams
Cc: Arnd Bergmann, linux-gpio, Linus Walleij, Vinod Koul,
Linux Kernel Mailing List, Bartosz Golaszewski, soc, linux-i2c,
dmaengine, Martin Michlmayr, linux-arm-kernel
On Fri, Aug 09, 2019 at 11:34:12AM -0700, Dan Williams wrote:
> [ add Martin (if cyrius.com address is still valid) ]
>
> On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > There are three families of IOP machines we support in Linux: iop32x
> > (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x).
> >
> > All products we support in the kernel are based on the first of these,
> > iop32x, the other families only ever supported the Intel reference
> > boards but no actual machine anyone could ever buy.
> >
> > While one could clearly make them all three work in a single kernel
> > with some work, this takes the easy way out, removing the later two
> > platforms entirely, under the assumption that there are no remaining
> > users.
> >
> > Earlier versions of OpenWRT and Debian both had support for iop32x
> > but not the others, and they both dropped iop32x as well in their 2015
> > releases.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > I'm just guessing that iop32x is still needed, and the other two are
> > not. If anyone disagrees with that assessment, let me know so we
> > can come up with an alternative approach.
>
> I'm not sure who would scream if iop32x support went away as well, but
> I have not followed this space in years hence copying Martin.
>
> In any event:
>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
Those of us who have and still run Thecus N2100's, for example?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
2019-08-09 18:36 ` Russell King - ARM Linux admin
@ 2019-08-09 19:43 ` Dan Williams
0 siblings, 0 replies; 23+ messages in thread
From: Dan Williams @ 2019-08-09 19:43 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Arnd Bergmann, linux-gpio, Linus Walleij, Vinod Koul,
Linux Kernel Mailing List, Bartosz Golaszewski, soc, linux-i2c,
dmaengine, Martin Michlmayr, Linux ARM
On Fri, Aug 9, 2019 at 11:37 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Aug 09, 2019 at 11:34:12AM -0700, Dan Williams wrote:
> > [ add Martin (if cyrius.com address is still valid) ]
> >
> > On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > There are three families of IOP machines we support in Linux: iop32x
> > > (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x).
> > >
> > > All products we support in the kernel are based on the first of these,
> > > iop32x, the other families only ever supported the Intel reference
> > > boards but no actual machine anyone could ever buy.
> > >
> > > While one could clearly make them all three work in a single kernel
> > > with some work, this takes the easy way out, removing the later two
> > > platforms entirely, under the assumption that there are no remaining
> > > users.
> > >
> > > Earlier versions of OpenWRT and Debian both had support for iop32x
> > > but not the others, and they both dropped iop32x as well in their 2015
> > > releases.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > I'm just guessing that iop32x is still needed, and the other two are
> > > not. If anyone disagrees with that assessment, let me know so we
> > > can come up with an alternative approach.
> >
> > I'm not sure who would scream if iop32x support went away as well, but
> > I have not followed this space in years hence copying Martin.
> >
> > In any event:
> >
> > Acked-by: Dan Williams <dan.j.williams@intel.com>
>
> Those of us who have and still run Thecus N2100's, for example?
Nice! Good to hear.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
2019-08-09 18:34 ` Dan Williams
2019-08-09 18:36 ` Russell King - ARM Linux admin
@ 2019-08-12 9:44 ` Martin Michlmayr
2019-08-14 8:36 ` Linus Walleij
1 sibling, 1 reply; 23+ messages in thread
From: Martin Michlmayr @ 2019-08-12 9:44 UTC (permalink / raw)
To: Dan Williams
Cc: Peter Teichmann, Arnd Bergmann, linux-gpio,
Linux Kernel Mailing List, Linus Walleij, soc, Russell King,
Bartosz Golaszewski, Vinod Koul, linux-i2c, dmaengine,
linux-arm-kernel
* Dan Williams <dan.j.williams@intel.com> [2019-08-09 11:34]:
> > Earlier versions of OpenWRT and Debian both had support for iop32x
> > but not the others, and they both dropped iop32x as well in their 2015
> > releases.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > I'm just guessing that iop32x is still needed, and the other two are
> > not. If anyone disagrees with that assessment, let me know so we
> > can come up with an alternative approach.
>
> I'm not sure who would scream if iop32x support went away as well, but
> I have not followed this space in years hence copying Martin.
I believe iop13xx were mostly Intel dev boards. I'm not aware of any
major devices based on iop33x.
As Arnd points out, Debian used to have support for various iop32x
devices. While Debian hasn't supported iop32x in a number of years,
these devices are still usable and in use (RMK being a prime example).
So I think it's safe to drop iop33x/iop13xx while retaining support
for iop32x.
As I was looking at my email archives, I saw an email from Peter
Teichmann who was working on an iop33x based platform (around 2009) so
I've copied him as well.
> In any event:
>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Martin Michlmayr <tbm@cyrius.com>
--
Martin Michlmayr
https://www.cyrius.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
2019-08-12 9:44 ` Martin Michlmayr
@ 2019-08-14 8:36 ` Linus Walleij
2019-08-14 10:48 ` Arnd Bergmann
2019-08-16 15:42 ` Aaro Koskinen
0 siblings, 2 replies; 23+ messages in thread
From: Linus Walleij @ 2019-08-14 8:36 UTC (permalink / raw)
To: Martin Michlmayr
Cc: Peter Teichmann, Arnd Bergmann, open list:GPIO SUBSYSTEM,
Linux Kernel Mailing List, soc, Russell King,
Bartosz Golaszewski, Vinod Koul, linux-i2c, dmaengine,
Dan Williams, Linux ARM
On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote:
> As Arnd points out, Debian used to have support for various iop32x
> devices. While Debian hasn't supported iop32x in a number of years,
> these devices are still usable and in use (RMK being a prime example).
I suppose it could be a good idea to add support for iop32x to
OpenWrt and/or OpenEmbedded, both of which support some
pretty constrained systems. I am personally using these
distributions to support elder ARM hardware these days.
Just my €0.01
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
2019-08-14 8:36 ` Linus Walleij
@ 2019-08-14 10:48 ` Arnd Bergmann
2019-08-16 15:42 ` Aaro Koskinen
1 sibling, 0 replies; 23+ messages in thread
From: Arnd Bergmann @ 2019-08-14 10:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Peter Teichmann, open list:GPIO SUBSYSTEM,
Linux Kernel Mailing List, Vinod Koul, Russell King,
Bartosz Golaszewski, soc, linux-i2c, dmaengine, Dan Williams,
Martin Michlmayr, Linux ARM
On Wed, Aug 14, 2019 at 10:36 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote:
>
> > As Arnd points out, Debian used to have support for various iop32x
> > devices. While Debian hasn't supported iop32x in a number of years,
> > these devices are still usable and in use (RMK being a prime example).
>
> I suppose it could be a good idea to add support for iop32x to
> OpenWrt and/or OpenEmbedded, both of which support some
> pretty constrained systems. I am personally using these
> distributions to support elder ARM hardware these days.
OpenWRT also had support in the past and dropped it around the
same time as Debian. The way I understand it, a couple of platforms
including iop32x were moved out of the main openwrt source tree
into https://github.com/openwrt/targets/ because there was little
interest in keeping them running.
The idea was that any remaining users could add that feed to get
minimal support, but I'm not sure if would still work. In particular,
iop33x appears to be based on linux-3.3 plus three patches that
are no longer needed in mainline. Building a mainline kernel without
those patches may or may not work.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
2019-08-14 8:36 ` Linus Walleij
2019-08-14 10:48 ` Arnd Bergmann
@ 2019-08-16 15:42 ` Aaro Koskinen
2019-08-16 15:58 ` Russell King - ARM Linux admin
1 sibling, 1 reply; 23+ messages in thread
From: Aaro Koskinen @ 2019-08-16 15:42 UTC (permalink / raw)
To: Linus Walleij
Cc: Vinod Koul, Peter Teichmann, Arnd Bergmann, Bartosz Golaszewski,
Linux Kernel Mailing List, Russell King,
open list:GPIO SUBSYSTEM, soc, linux-i2c, dmaengine,
Dan Williams, Martin Michlmayr, Linux ARM
Hi,
On Wed, Aug 14, 2019 at 10:36:01AM +0200, Linus Walleij wrote:
> On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote:
> > As Arnd points out, Debian used to have support for various iop32x
> > devices. While Debian hasn't supported iop32x in a number of years,
> > these devices are still usable and in use (RMK being a prime example).
>
> I suppose it could be a good idea to add support for iop32x to
> OpenWrt and/or OpenEmbedded, both of which support some
> pretty constrained systems.
This platform is not really too constrained... E.g. on N2100 you have
512 MB RAM, SATA disks and gigabit ethernet. Not that different from
mvebu that Debian currently (?) supports. Maybe with multiplatform they
could support iop32x again.
A.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
2019-08-16 15:42 ` Aaro Koskinen
@ 2019-08-16 15:58 ` Russell King - ARM Linux admin
2019-08-16 16:15 ` Aaro Koskinen
0 siblings, 1 reply; 23+ messages in thread
From: Russell King - ARM Linux admin @ 2019-08-16 15:58 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Vinod Koul, Peter Teichmann, Arnd Bergmann, Bartosz Golaszewski,
Linus Walleij, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, soc, linux-i2c, dmaengine,
Dan Williams, Martin Michlmayr, Linux ARM
On Fri, Aug 16, 2019 at 06:42:49PM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Aug 14, 2019 at 10:36:01AM +0200, Linus Walleij wrote:
> > On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote:
> > > As Arnd points out, Debian used to have support for various iop32x
> > > devices. While Debian hasn't supported iop32x in a number of years,
> > > these devices are still usable and in use (RMK being a prime example).
> >
> > I suppose it could be a good idea to add support for iop32x to
> > OpenWrt and/or OpenEmbedded, both of which support some
> > pretty constrained systems.
>
> This platform is not really too constrained... E.g. on N2100 you have
> 512 MB RAM, SATA disks and gigabit ethernet. Not that different from
> mvebu that Debian currently (?) supports. Maybe with multiplatform they
> could support iop32x again.
Probably not. The kernel has a dividing line between ARMv5 and ARMv6
where it's not possible to multiplatform across that boundary, so
you're already needing separate kernel images there.
Secondly, armhf distros won't be compatible with ARMv5, and to make
them compatible will make performance on armhf suffer - you have to
stop using barriers, exclusive load/store and a few other things.
You have to rely on the kuser page exported by the kernel (which is
now optional as it's deemed to be a security issue for ROP attacks)
for some things that such a userspace requires - such as NPTL support.
Effectively, ARMv5 is an entirely separate userspace distro from armhf.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
2019-08-16 15:58 ` Russell King - ARM Linux admin
@ 2019-08-16 16:15 ` Aaro Koskinen
0 siblings, 0 replies; 23+ messages in thread
From: Aaro Koskinen @ 2019-08-16 16:15 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Vinod Koul, Peter Teichmann, Arnd Bergmann, Bartosz Golaszewski,
Linus Walleij, Linux Kernel Mailing List,
open list:GPIO SUBSYSTEM, soc, linux-i2c, dmaengine,
Dan Williams, Martin Michlmayr, Linux ARM
Hi,
On Fri, Aug 16, 2019 at 04:58:33PM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Aug 16, 2019 at 06:42:49PM +0300, Aaro Koskinen wrote:
> > On Wed, Aug 14, 2019 at 10:36:01AM +0200, Linus Walleij wrote:
> > > On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr <tbm@cyrius.com> wrote:
> > > > As Arnd points out, Debian used to have support for various iop32x
> > > > devices. While Debian hasn't supported iop32x in a number of years,
> > > > these devices are still usable and in use (RMK being a prime example).
> > >
> > > I suppose it could be a good idea to add support for iop32x to
> > > OpenWrt and/or OpenEmbedded, both of which support some
> > > pretty constrained systems.
> >
> > This platform is not really too constrained... E.g. on N2100 you have
> > 512 MB RAM, SATA disks and gigabit ethernet. Not that different from
> > mvebu that Debian currently (?) supports. Maybe with multiplatform they
> > could support iop32x again.
>
> Probably not. The kernel has a dividing line between ARMv5 and ARMv6
> where it's not possible to multiplatform across that boundary, so
> you're already needing separate kernel images there.
>
> Secondly, armhf distros won't be compatible with ARMv5, and to make
> them compatible will make performance on armhf suffer - you have to
> stop using barriers, exclusive load/store and a few other things.
> You have to rely on the kuser page exported by the kernel (which is
> now optional as it's deemed to be a security issue for ROP attacks)
> for some things that such a userspace requires - such as NPTL support.
>
> Effectively, ARMv5 is an entirely separate userspace distro from armhf.
I thought they still had armel for ARMv5 and mvebu (kirkwood).
A.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 23+ messages in thread