This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Move the common code for ts72xx and BK3 to ts72xx-common.c - this
code can be reused by other designs build around ts72xx
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c
Lukasz Majewski (4):
ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Exclude reusable part of the ts72xx board
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
arch/arm/mach-ep93xx/Kconfig | 11 +++
arch/arm/mach-ep93xx/Makefile | 2 +
arch/arm/mach-ep93xx/bk3.c | 88 +++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx-common.c | 158 +++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.c | 136 ++----------------------------
arch/arm/mach-ep93xx/ts72xx.h | 14 ++++
arch/arm/tools/mach-types | 1 +
7 files changed, 279 insertions(+), 131 deletions(-)
create mode 100644 arch/arm/mach-ep93xx/bk3.c
create mode 100644 arch/arm/mach-ep93xx/ts72xx-common.c
--
2.11.0
This commit cleans up the code by using dedicated macros instead of
full definitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
arch/arm/mach-ep93xx/ts72xx.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
This commit creates a new file ts72xx-common.c [1], which consists
of code being potentially re-usable by other clones of reference
ts72xx design.
To achieve this goal, a new symbol - TS72XX_COMMON has been introduced.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
arch/arm/mach-ep93xx/Kconfig | 4 +
arch/arm/mach-ep93xx/Makefile | 1 +
arch/arm/mach-ep93xx/ts72xx-common.c | 158 +++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.c | 122 +--------------------------
arch/arm/mach-ep93xx/ts72xx.h | 5 ++
5 files changed, 172 insertions(+), 118 deletions(-)
create mode 100644 arch/arm/mach-ep93xx/ts72xx-common.c
@@ -49,50 +44,10 @@ static struct map_desc ts72xx_io_desc[] __initdata = {staticvoid__initts72xx_map_io(void){-ep93xx_map_io();+ts72xx_common_map_io();iotable_init(ts72xx_io_desc,ARRAY_SIZE(ts72xx_io_desc));}--/*************************************************************************-*NANDflash-*************************************************************************/-#define TS72XX_NAND_CONTROL_ADDR_LINE 22 /* 0xN0400000 */-#define TS72XX_NAND_BUSY_ADDR_LINE 23 /* 0xN0800000 */--staticvoidts72xx_nand_hwcontrol(structmtd_info*mtd,-intcmd,unsignedintctrl)-{-structnand_chip*chip=mtd_to_nand(mtd);--if(ctrl&NAND_CTRL_CHANGE){-void__iomem*addr=chip->IO_ADDR_R;-unsignedcharbits;--addr+=(1<<TS72XX_NAND_CONTROL_ADDR_LINE);--bits=__raw_readb(addr)&~0x07;-bits|=(ctrl&NAND_NCE)<<2;/* bit 0 -> bit 2 */-bits|=(ctrl&NAND_CLE);/* bit 1 -> bit 1 */-bits|=(ctrl&NAND_ALE)>>2;/* bit 2 -> bit 0 */--__raw_writeb(bits,addr);-}--if(cmd!=NAND_CMD_NONE)-__raw_writeb(cmd,chip->IO_ADDR_W);-}--staticintts72xx_nand_device_ready(structmtd_info*mtd)-{-structnand_chip*chip=mtd_to_nand(mtd);-void__iomem*addr=chip->IO_ADDR_R;--addr+=(1<<TS72XX_NAND_BUSY_ADDR_LINE);--return!!(__raw_readb(addr)&0x20);-}-#define TS72XX_BOOTROM_PART_SIZE (SZ_16K)#define TS72XX_REDBOOT_PART_SIZE (SZ_2M + SZ_1M)
@@ -115,59 +70,6 @@ static struct mtd_partition ts72xx_nand_parts[] = {},};-staticstructplatform_nand_datats72xx_nand_data={-.chip={-.nr_chips=1,-.chip_offset=0,-.chip_delay=15,-.partitions=ts72xx_nand_parts,-.nr_partitions=ARRAY_SIZE(ts72xx_nand_parts),-},-.ctrl={-.cmd_ctrl=ts72xx_nand_hwcontrol,-.dev_ready=ts72xx_nand_device_ready,-},-};--staticstructresourcets72xx_nand_resource[]={-{-.start=0,/* filled in later */-.end=0,/* filled in later */-.flags=IORESOURCE_MEM,-},-};--staticstructplatform_devicets72xx_nand_flash={-.name="gen_nand",-.id=-1,-.dev.platform_data=&ts72xx_nand_data,-.resource=ts72xx_nand_resource,-.num_resources=ARRAY_SIZE(ts72xx_nand_resource),-};---staticvoid__initts72xx_register_flash(void)-{-/*-*TS7200hasNORflashallotherTS72xxboardhaveNANDflash.-*/-if(board_is_ts7200()){-ep93xx_register_flash(2,EP93XX_CS6_PHYS_BASE,SZ_16M);-}else{-resource_size_tstart;--if(is_ts9420_installed())-start=EP93XX_CS7_PHYS_BASE;-else-start=EP93XX_CS6_PHYS_BASE;--ts72xx_nand_resource[0].start=start;-ts72xx_nand_resource[0].end=start+SZ_16M-1;--platform_device_register(&ts72xx_nand_flash);-}-}-/**************************************************************************RTCM48T86*************************************************************************/
From: Alexander Sverdlin <alexander.sverdlin@gmail.com> Date: 2017-11-19 21:28:10
Hello Lukasz!
On 17/11/17 00:22, Lukasz Majewski wrote:
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Move the common code for ts72xx and BK3 to ts72xx-common.c - this
code can be reused by other designs build around ts72xx
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c
Lukasz Majewski (4):
ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable
The patch 3/4 deletes everything added by patch 1/4, so I don't really see the point of it.
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Exclude reusable part of the ts72xx board
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
I tend to agree with Hartley, if you'd just add all BK3-related extras to ts72xx.c it would
be less than 60 LoCs, you probably even do not need new Kconfig options.
Alex.
Hello Lukasz!
On 17/11/17 00:22, Lukasz Majewski wrote:
quoted
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Move the common code for ts72xx and BK3 to ts72xx-common.c - this
code can be reused by other designs build around ts72xx
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c
Lukasz Majewski (4):
ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable
The patch 3/4 deletes everything added by patch 1/4, so I don't
really see the point of it.
I wanted to first clean up things.
quoted
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Exclude reusable part of the ts72xx board
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx
derivative
I tend to agree with Hartley, if you'd just add all BK3-related
extras to ts72xx.c it would be less than 60 LoCs, you probably even
do not need new Kconfig options.
Some Kconfig option would be welcome (MACH_BK3 ?) if it turns out that I
do need to adjust some things later (like change HAMMING NAND ECC to BCH
for plat_nand driver).
The separate bk3.c file is more appealing (for me) in terms of extending
the code latter.
Alex.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171120/d0ce35fc/attachment.sig>
On Mon, Nov 20, 2017 at 12:23 AM, Lukasz Majewski [off-list ref] wrote:
Hi Alexander,
quoted
Hello Lukasz!
On 17/11/17 00:22, Lukasz Majewski wrote:
quoted
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Move the common code for ts72xx and BK3 to ts72xx-common.c - this
code can be reused by other designs build around ts72xx
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c
Lukasz Majewski (4):
ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable
The patch 3/4 deletes everything added by patch 1/4, so I don't
really see the point of it.
I wanted to first clean up things.
Cleaning it up first is the right approach, a patch that moves code around
should not contain any other changes.
quoted
quoted
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Exclude reusable part of the ts72xx board
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx
derivative
I tend to agree with Hartley, if you'd just add all BK3-related
extras to ts72xx.c it would be less than 60 LoCs, you probably even
do not need new Kconfig options.
Some Kconfig option would be welcome (MACH_BK3 ?) if it turns out that I
do need to adjust some things later (like change HAMMING NAND ECC to BCH
for plat_nand driver).
The separate bk3.c file is more appealing (for me) in terms of extending
the code latter.
I think keeping everything in one file, but adding a new Kconfig option that
uses 'select MACH_TS72XX' to enable the existing board would be simpler,
we can split it out later once we think it gets too big.
Arnd
On Mon, Nov 20, 2017 at 12:23 AM, Lukasz Majewski [off-list ref]
wrote:
quoted
Hi Alexander,
quoted
Hello Lukasz!
On 17/11/17 00:22, Lukasz Majewski wrote:
quoted
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Move the common code for ts72xx and BK3 to ts72xx-common.c -
this code can be reused by other designs build around ts72xx
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c
Lukasz Majewski (4):
ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where
applicable
The patch 3/4 deletes everything added by patch 1/4, so I don't
really see the point of it.
I wanted to first clean up things.
Cleaning it up first is the right approach, a patch that moves code
around should not contain any other changes.
quoted
quoted
quoted
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Exclude reusable part of the ts72xx board
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx
derivative
I tend to agree with Hartley, if you'd just add all BK3-related
extras to ts72xx.c it would be less than 60 LoCs, you probably even
do not need new Kconfig options.
Some Kconfig option would be welcome (MACH_BK3 ?) if it turns out
that I do need to adjust some things later (like change HAMMING
NAND ECC to BCH for plat_nand driver).
The separate bk3.c file is more appealing (for me) in terms of
extending the code latter.
I think keeping everything in one file, but adding a new Kconfig
option that uses 'select MACH_TS72XX' to enable the existing board
would be simpler, we can split it out later once we think it gets too
big.
Ok. Thanks for the suggestion. I will prepare v2.
Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171120/aceeacbd/attachment.sig>
This commit cleans up the code by using dedicated macros instead of
full definitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c
This series applies on top of v4.14
Lukasz Majewski (6):
ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: Rewrite map IO code to be reusable
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
arch/arm/mach-ep93xx/Kconfig | 7 +++
arch/arm/mach-ep93xx/ts72xx.c | 137 +++++++++++++++++++++++++++++++-----------
arch/arm/mach-ep93xx/ts72xx.h | 9 +++
arch/arm/tools/mach-types | 1 +
4 files changed, 120 insertions(+), 34 deletions(-)
--
2.11.0
This commit extend the ts72xx_register_flash() to accept passed parameters,
which makes it more reusable.
Now it is possible to accept ep93xx flash start address and partitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- New patch
---
arch/arm/mach-ep93xx/ts72xx.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
The map IO common code has been excluded to be reused by other ts72xx
clones.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- New patch
---
arch/arm/mach-ep93xx/ts72xx.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
The BK3 board is a derivative of the ts72xx reference design.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Place bk3 support code to the ts72xx.c file
---
arch/arm/mach-ep93xx/Kconfig | 7 +++++
arch/arm/mach-ep93xx/ts72xx.c | 64 +++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.h | 5 ++++
arch/arm/tools/mach-types | 1 +
4 files changed, 77 insertions(+)
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c
This series applies on top of v4.14
Do you have any comments regarding this patch series?
Lukasz Majewski (6):
ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: Rewrite map IO code to be reusable
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
arch/arm/mach-ep93xx/Kconfig | 7 +++
arch/arm/mach-ep93xx/ts72xx.c | 137
+++++++++++++++++++++++++++++++-----------
arch/arm/mach-ep93xx/ts72xx.h | 9 +++ arch/arm/tools/mach-types
| 1 + 4 files changed, 120 insertions(+), 34 deletions(-)
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171129/72d37d17/attachment.sig>
On Wed, Nov 29, 2017 at 10:45 AM, Lukasz Majewski [off-list ref] wrote:
Dear All,
quoted
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c
This series applies on top of v4.14
Do you have any comments regarding this patch series?
From: Alexander Sverdlin <alexander.sverdlin@gmail.com> Date: 2017-11-29 20:48:27
Hello Lukasz,
some nitpicking below...
On 21/11/17 15:32, Lukasz Majewski wrote:
quoted hunk
The BK3 board is a derivative of the ts72xx reference design.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Place bk3 support code to the ts72xx.c file
---
arch/arm/mach-ep93xx/Kconfig | 7 +++++
arch/arm/mach-ep93xx/ts72xx.c | 64 +++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.h | 5 ++++
arch/arm/tools/mach-types | 1 +
4 files changed, 77 insertions(+)
From: Alexander Sverdlin <alexander.sverdlin@gmail.com> Date: 2017-11-29 20:54:43
Hi!
On 21/11/17 15:32, Lukasz Majewski wrote:
This commit extend the ts72xx_register_flash() to accept passed parameters,
which makes it more reusable.
Now it is possible to accept ep93xx flash start address and partitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
quoted hunk
---
Changes for v2:
- New patch
---
arch/arm/mach-ep93xx/ts72xx.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
Hello Lukasz,
some nitpicking below...
On 21/11/17 15:32, Lukasz Majewski wrote:
quoted
The BK3 board is a derivative of the ts72xx reference design.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Place bk3 support code to the ts72xx.c file
---
arch/arm/mach-ep93xx/Kconfig | 7 +++++
arch/arm/mach-ep93xx/ts72xx.c | 64
+++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.h | 5 ++++
arch/arm/tools/mach-types | 1 + 4 files changed, 77
insertions(+)
diff --git a/arch/arm/mach-ep93xx/Kconfig
b/arch/arm/mach-ep93xx/Kconfig index 61a75ca3684e..c095236d7ff8
100644 --- a/arch/arm/mach-ep93xx/Kconfig
Don't you want to add an entry to the MAINTAINERS file instead?
Then get_maintainer.pl would be able to suggest your email.
Yes. This would be a good idea (I've followed the "style" of other
boards in the mach-ep93xx directory).
I will fix that ....... and send v3 with included some extra code - as
I've found and fixed several issues since last posting.
Anyway, many thanks for review.
quoted
+ .atag_offset = 0x100,
+ .map_io = bk3_map_io,
again, inconsistent alignment...
Even more..... checkpatch.pl did not complained....
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171129/1e13ddbe/attachment.sig>
On Wed, 29 Nov 2017 23:07:04 +0100
Lukasz Majewski [off-list ref] wrote:
Hi Alexander,
quoted
Hello Lukasz,
some nitpicking below...
On 21/11/17 15:32, Lukasz Majewski wrote:
quoted
The BK3 board is a derivative of the ts72xx reference design.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Place bk3 support code to the ts72xx.c file
---
arch/arm/mach-ep93xx/Kconfig | 7 +++++
arch/arm/mach-ep93xx/ts72xx.c | 64
+++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.h | 5 ++++
arch/arm/tools/mach-types | 1 + 4 files changed, 77
insertions(+)
diff --git a/arch/arm/mach-ep93xx/Kconfig
b/arch/arm/mach-ep93xx/Kconfig index 61a75ca3684e..c095236d7ff8
100644 --- a/arch/arm/mach-ep93xx/Kconfig
Don't you want to add an entry to the MAINTAINERS file instead?
Then get_maintainer.pl would be able to suggest your email.
Yes. This would be a good idea (I've followed the "style" of other
boards in the mach-ep93xx directory).
I will fix that ....... and send v3 with included some extra code - as
I've found and fixed several issues since last posting.
Anyway, many thanks for review.
quoted
quoted
+ .atag_offset = 0x100,
+ .map_io = bk3_map_io,
again, inconsistent alignment...
Even more..... checkpatch.pl did not complained....
I've double checked - this misalignment seems to be only in e-mail.
In the ts72xx.c file it is all "tabifi'ed".
(and no checkpatch errors).
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171130/1b620095/attachment.sig>
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c (detalied list of changes can be found in patch 6/6)
This series applies on top of v4.14
Lukasz Majewski (6):
ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: Rewrite map IO code to be reusable
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 ++
arch/arm/mach-ep93xx/ts72xx.c | 222 +++++++++++++++++++++++++++++++++++-------
arch/arm/mach-ep93xx/ts72xx.h | 9 ++
arch/arm/tools/mach-types | 1 +
5 files changed, 211 insertions(+), 34 deletions(-)
--
2.11.0
This commit cleans up the code by using dedicated macros instead of
full definitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- None
Changes for v3:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
The map IO common code has been excluded to be reused by other ts72xx
clones.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- New patch
Changes for v3:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
This commit extend the ts72xx_register_flash() to accept passed parameters,
which makes it more reusable.
Now it is possible to accept ep93xx flash start address and partitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- New patch
Changes for v3:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
This is strange.... I'm using emacs with extension to have coding style
for kernel.
Probably tabs get unaligned...
Yes, seems that they are.
[...]
quoted
quoted
+ .atag_offset = 0x100,
+ .map_io = bk3_map_io,
again, inconsistent alignment...
Even more..... checkpatch.pl did not complained....
checkpatch.pl wouldn't complain, as there are basically two styles,
some people do not align the individual assignments in the structures at all.
But I was quite confident in the beginning and now even applied your v3 to
the code. And indeed it's unaligned... I even checked with emacs. Still
unaligned.
--
Alexander Sverdlin.
On Thu, Nov 30, 2017 at 1:45 AM, Lukasz Majewski [off-list ref] wrote:
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c (detalied list of changes can be found in patch 6/6)
This series applies on top of v4.14
Can we clarify who is picking up ep93xx patches these days? The
last time I think Linus Walleij offered to do it for the 4.14 merge window,
as neither Hartley nor Alexander had a git tree.
I don't care too much who does it in the end, between Hartley, Alexander,
Linus and even Lukasz directly, but I'd like whoever feels responsible
for the platform to be listed in the MAINTAINERS file and pick up
the patches from everyone else to forward them to me as either
pull requests or separate patches to arm at kernel.org when the
patches are ready, so I don't have to make a decision about when to
pick them up from the list.
Arnd
Hello Arnd!
On Thu Nov 30 10:02:26 2017 Arnd Bergmann [off-list ref] wrote:
Can we clarify who is picking up ep93xx patches these days? The
last time I think Linus Walleij offered to do it for the 4.14 merge
window, as neither Hartley nor Alexander had a git tree.
I don't care too much who does it in the end, between Hartley, Alexander,
Linus and even Lukasz directly, but I'd like whoever feels responsible
for the platform to be listed in the MAINTAINERS file and pick up
the patches from everyone else to forward them to me as either
pull requests or separate patches to arm at kernel.org when the
patches are ready, so I don't have to make a decision about when to
pick them up from the list.
As I stepped in as a maintainer there was a common understanding, that ep93xx is so inactive these days, that is doesn't deserve a separate tree. But I feel also that we will benefit from one, so let me create one this evening and I'll send you pull request when we agree with Lukasz. Just let me know if you'd be fine with github or should I care about kernel.org?
--
Regards,
Alexander.
On Thu, Nov 30, 2017 at 10:57 AM, Alexander Sverdlin
[off-list ref] wrote:
Hello Arnd!
On Thu Nov 30 10:02:26 2017 Arnd Bergmann [off-list ref] wrote:
quoted
Can we clarify who is picking up ep93xx patches these days? The
last time I think Linus Walleij offered to do it for the 4.14 merge
window, as neither Hartley nor Alexander had a git tree.
I don't care too much who does it in the end, between Hartley, Alexander,
Linus and even Lukasz directly, but I'd like whoever feels responsible
for the platform to be listed in the MAINTAINERS file and pick up
the patches from everyone else to forward them to me as either
pull requests or separate patches to arm at kernel.org when the
patches are ready, so I don't have to make a decision about when to
pick them up from the list.
As I stepped in as a maintainer there was a common understanding, that
ep93xx is so inactive these days, that is doesn't deserve a separate tree.
But I feel also that we will benefit from one, so let me create one this
evening and I'll send you pull request when we agree with Lukasz.
Just let me know if you'd be fine with github or should I care about
kernel.org?
Up to you. Normally I try to avoid github for more active trees, but
if you don't already have kernel.org account, it's probably not worth
the effort of getting one just for the few ep93xx patches. As I said,
we're probably also fine with picking up the patches individually,
as long as the process is clear to everyone, i.e. you pick up the
patches from any other contributors and notify them about the
status of their patches, and then you send them to arm at kernel.org
in whatever way makes most sense for you.
Arnd
On Wednesday, November 29, 2017 5:45 PM, Lukasz Majewski wrote:
This commit cleans up the code by using dedicated macros instead of full definitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Lukasz,
The chunk above is already cleaned up in linux-next by:
commit 97c3bca922468996c864917c9a8ea6a410233985
ARM: ep93xx: tidy up TS-72xx Watchdog resources
Can you please rebase this series against linux-next?
I'm reviewing the rest of the series now and will reply with any other issues.
Thanks,
Hartley
On Wednesday, November 29, 2017 5:45 PM, Lukasz Majewski wrote:
This commit extend the ts72xx_register_flash() to accept passed parameters, which makes it more reusable.
Now it is possible to accept ep93xx flash start address and partitions.
On Wednesday, November 29, 2017 5:45 PM, Lukasz Majewski wrote:
The map IO common code has been excluded to be reused by other ts72xx clones.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
There is also something funny with the patch. The lines above appear to be getting split incorrectly.
The same thing is seen in PATCH 6/6.
Please rebase the series against linux-next and I'll take another look at is.
Thanks,
Hartley
There is also something funny with the patch. The lines above appear to be getting split incorrectly.
That's definitely not the case, I can apply the patch to 4.14 just fine and
there is no funny wrapping. But you are right about the rest, it should be
re-based.
--
Alexander Sverdlin.
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c (detalied list of changes can be found in patch 6/6)
This series applies on top of linux-next/master (next-20171130)
Lukasz Majewski (5):
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: Rewrite map IO code to be reusable
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 ++
arch/arm/mach-ep93xx/ts72xx.c | 198 ++++++++++++++++++++++++++++++++++++++----
arch/arm/mach-ep93xx/ts72xx.h | 9 ++
arch/arm/tools/mach-types | 1 +
5 files changed, 202 insertions(+), 19 deletions(-)
--
2.11.0
The map IO common code has been excluded to be reused by other ts72xx
clones.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes for v4:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
The BK3 board is a derivative of the ts72xx reference design.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Place bk3 support code to the ts72xx.c file
Changes for v3:
- Add SD card support (via SPI) for BK3
- Remove definition of apb:i2s bus
- Remove board registration of CPLD WDT device
- Add I2S platform device to BK3
- Add MAINTAINERS entry for BK3 maintainer
Changes for v4:
- Adjust the code to be applicable on top of linux-next/master
---
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 ++
arch/arm/mach-ep93xx/ts72xx.c | 146 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.h | 5 ++
arch/arm/tools/mach-types | 1 +
5 files changed, 165 insertions(+)
This patch extends readability of ts72xx.c code.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes to v4:
- Adjust the code to be applicable to linux-next/master
---
arch/arm/mach-ep93xx/ts72xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
This commit extend the ts72xx_register_flash() to accept passed parameters,
which makes it more reusable.
Now it is possible to accept ep93xx flash start address and partitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes for v4:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
On Thursday, November 30, 2017 4:52 PM, Lukasz Majewski wrote:
This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c (detalied list of changes can be found in patch 6/6)
This series applies on top of linux-next/master (next-20171130)
Lukasz Majewski (5):
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: Rewrite map IO code to be reusable
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 ++
arch/arm/mach-ep93xx/ts72xx.c | 198 ++++++++++++++++++++++++++++++++++++++----
arch/arm/mach-ep93xx/ts72xx.h | 9 ++
arch/arm/tools/mach-types | 1 +
5 files changed, 202 insertions(+), 19 deletions(-)
Looks good.
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Linus,
Would you mind picking this series up?
Thanks,
Hartley
From: Alexander Sverdlin <alexander.sverdlin@gmail.com> Date: 2017-12-06 17:46:29
Hello Hartley,
On 05/12/17 19:14, Hartley Sweeten wrote:
quoted
This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c (detalied list of changes can be found in patch 6/6)
This series applies on top of linux-next/master (next-20171130)
Lukasz Majewski (5):
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: Rewrite map IO code to be reusable
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 ++
arch/arm/mach-ep93xx/ts72xx.c | 198 ++++++++++++++++++++++++++++++++++++++----
arch/arm/mach-ep93xx/ts72xx.h | 9 ++
arch/arm/tools/mach-types | 1 +
5 files changed, 202 insertions(+), 19 deletions(-)
Looks good.
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
I can prepare pull request to Arnd, as we discussed previously, just
waited for your review.
Regards,
Alexander.
This register appears to be common to all the TS-72xx boards.
I don't think Arnd has pulled the series yet. Would you mind renaming the
defines and rebasing this patch? The BK3 board and other TS-72xx boards
can then have a common .map_io.
Thanks,
Hartley
This register appears to be common to all the TS-72xx boards.
The CPLD was used on the reference ts-72xx boards, but support for it
seems to not be present in the mainline kernel.
Do you have a ts72xx board with CPLD embedded? Is any of your design
using it?
My another concern - is it safe to perform IO mapping on memory regions
which are not used / specified? When I do a single ts72xx mapping - for
all boards - then we may end up with some mappings which are not needed.
With the code as it is - I only map regions which are already used on
relevant boards.
I don't think Arnd has pulled the series yet. Would you mind renaming
the defines and rebasing this patch?
If needed I can resend the patch series, or prepare a single fix patch.
No problem.
The BK3 board and other TS-72xx
boards can then have a common .map_io.
Thanks,
Hartley
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171211/0cfc9f29/attachment.sig>
This register appears to be common to all the TS-72xx boards.
The CPLD was used on the reference ts-72xx boards, but support for it seems
to not be present in the mainline kernel.
The CPLD is not directly called out but some parts of it are supported in the mainline
kernel.
The RTC index and data registers are chip selected by the CPLD and Watchdog is in
the CPLD. Also, the model number, options, and options2 registers are in the CPLD.
There are a couple other registers in the CPLD that are not currently present in
mainline. Some aren't because I haven't figured a good way to utilize them (the
COM2 RS485 registers and the PC/104 memory/IO spaces) or they simply have not
been necessary yet (the two status registers). There are a couple listed in the manuals
that are specific to the TS-7260 that also have not been added.
Basically, anything in the EP93xx CS1 or CS2 memory region is in or controlled by the CPLD.
Do you have a ts72xx board with CPLD embedded? Is any of your design using it?
I have a stock TS-7300 board.
My another concern - is it safe to perform IO mapping on memory regions which are
not used / specified?
The mapping is safe. If there is nothing at the address you just read back the static state
(noise) of the bus and writing doesn't do anything.
When I do a single ts72xx mapping - for all boards - then we may end up with some
mappings which are not needed.
True, but it's harmless and it keeps the platform init code cleaner.
With the code as it is - I only map regions which are already used on relevant boards.
Yes, but this register in particular exists in the CPLD on all the TS-72xx boards.
quoted
I don't think Arnd has pulled the series yet. Would you mind renaming
the defines and rebasing this patch?
If needed I can resend the patch series, or prepare a single fix patch.
No problem.
Fixing it after Arnd merges your series is fine. I just wanted to make sure it was
pointed out.
BTW, is there a reason the BK3 board needs this register mapped? It was mapped
in the Technologic Systems 2.4, 2.6, and 3.x kernels but I never found anything that
used it. Of course the stock boards probably always had the same revision in the CPLD,
the BK3 board might have multiple revisions...
Hartley
This register appears to be common to all the TS-72xx boards.
The CPLD was used on the reference ts-72xx boards, but support for
it seems to not be present in the mainline kernel.
The CPLD is not directly called out but some parts of it are
supported in the mainline kernel.
The RTC index and data registers are chip selected by the CPLD and
Watchdog is in the CPLD. Also, the model number, options, and
options2 registers are in the CPLD.
There are a couple other registers in the CPLD that are not currently
present in mainline. Some aren't because I haven't figured a good way
to utilize them (the COM2 RS485 registers and the PC/104 memory/IO
spaces) or they simply have not been necessary yet (the two status
registers). There are a couple listed in the manuals that are
specific to the TS-7260 that also have not been added.
Basically, anything in the EP93xx CS1 or CS2 memory region is in or
controlled by the CPLD.
quoted
Do you have a ts72xx board with CPLD embedded? Is any of your
design using it?
I have a stock TS-7300 board.
quoted
My another concern - is it safe to perform IO mapping on memory
regions which are not used / specified?
The mapping is safe. If there is nothing at the address you just read
back the static state (noise) of the bus and writing doesn't do
anything.
Ok.
quoted
When I do a single ts72xx mapping - for all boards - then we may
end up with some mappings which are not needed.
True, but it's harmless and it keeps the platform init code cleaner.
I will add all the mappings.
quoted
With the code as it is - I only map regions which are already used
on relevant boards.
Yes, but this register in particular exists in the CPLD on all the
TS-72xx boards.
quoted
quoted
I don't think Arnd has pulled the series yet. Would you mind
renaming the defines and rebasing this patch?
If needed I can resend the patch series, or prepare a single fix
patch. No problem.
Fixing it after Arnd merges your series is fine. I just wanted to
make sure it was pointed out.
I've checked a few minutes ago and it seems like arm-soc hasn't been
pulled to for-next.
I may resend the whole series.
BTW, is there a reason the BK3 board needs this register mapped? It
was mapped in the Technologic Systems 2.4, 2.6, and 3.x kernels but I
never found anything that used it.
It is used to check the version. BK3 has some CPLD modifications and
it is important to know which version we do have as the board is
already deployed for some time in the field.
Of course the stock boards
probably always had the same revision in the CPLD, the BK3 board
might have multiple revisions...
Yes, correct.
Hartley
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171211/4003dd39/attachment-0001.sig>
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c (detalied list of changes can be found in patch 4/4)
This series applies on top of linux-next/master (next-20171211)
Lukasz Majewski (4):
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 ++
arch/arm/mach-ep93xx/ts72xx.c | 165 +++++++++++++++++++++++++++++++++++++++---
arch/arm/mach-ep93xx/ts72xx.h | 9 +++
arch/arm/tools/mach-types | 1 +
5 files changed, 176 insertions(+), 12 deletions(-)
--
2.11.0
This patch extends readability of ts72xx.c code.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes to v4:
- Adjust the code to be applicable to linux-next/master
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
The BK3 board is a derivative of the ts72xx reference design.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Place bk3 support code to the ts72xx.c file
Changes for v3:
- Add SD card support (via SPI) for BK3
- Remove definition of apb:i2s bus
- Remove board registration of CPLD WDT device
- Add I2S platform device to BK3
- Add MAINTAINERS entry for BK3 maintainer
Changes for v4:
- Adjust the code to be applicable on top of linux-next/master
Changes for v5:
- Combine map_io to be reused across all ts72xx boards
---
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 +++
arch/arm/mach-ep93xx/ts72xx.c | 136 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.h | 5 ++
arch/arm/tools/mach-types | 1 +
5 files changed, 155 insertions(+)
This commit extend the ts72xx_register_flash() to accept passed parameters,
which makes it more reusable.
Now it is possible to accept ep93xx flash start address and partitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
On Monday, December 11, 2017 4:36 PM, Lukasz Majewski wrote:
This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c (detalied list of changes can be found in patch 4/4)
This series applies on top of linux-next/master (next-20171211)
Lukasz Majewski (4):
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 ++
arch/arm/mach-ep93xx/ts72xx.c | 165 +++++++++++++++++++++++++++++++++++++++---
arch/arm/mach-ep93xx/ts72xx.h | 9 +++
arch/arm/tools/mach-types | 1 +
5 files changed, 176 insertions(+), 12 deletions(-)
Looks good. Thanks!
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski [off-list ref] wrote:
This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
All looks good.
Acked-by: Linus Walleij <redacted>
Out of curiosity: Liebherr is obviously doing heavy-duty industrial
control systems. Likewise Hartley is doing similar business over
at Vision Engravings.
Is the situation such that there is a whole bunch of industrial
systems out there, in active use and needing future upgrades,
that use the EP93xx?
Arnd has been nudging me to do DT conversion for EP93xx
so if there are many active industrial users of these
I should prioritize it, because these things have 20+ years
support cycles.
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
Yours,
Linus Walleij
From: Alexander Sverdlin <alexander.sverdlin@gmail.com> Date: 2017-12-13 08:26:18
Hello Linus!
On Wed Dec 13 08:34:22 2017 Linus Walleij [off-list ref] wrote:
On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski [off-list ref] wrote:
Out of curiosity: Liebherr is obviously doing heavy-duty industrial
control systems. Likewise Hartley is doing similar business over
at Vision Engravings.
Is the situation such that there is a whole bunch of industrial
systems out there, in active use and needing future upgrades,
that use the EP93xx?
That's definitely the case. I'm as well aware of several thousands of industrial devices which are expected to run 24/7 for the next 5 years at least. And they are updated from time to time.
Arnd has been nudging me to do DT conversion for EP93xx
so if there are many active industrial users of these
I should prioritize it, because these things have 20+ years
support cycles.
I'm not sure how important or necessary at all is to change anything in these legacy platforms.
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
But we should definitely preserve at least what we have.
--
Alexander.
Hello Linus!
On Wed Dec 13 08:34:22 2017 Linus Walleij [off-list ref]
wrote:
quoted
On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski [off-list ref]
wrote: Out of curiosity: Liebherr is obviously doing heavy-duty
industrial control systems. Likewise Hartley is doing similar
business over at Vision Engravings.
Is the situation such that there is a whole bunch of industrial
systems out there, in active use and needing future upgrades,
that use the EP93xx?
That's definitely the case. I'm as well aware of several thousands of
industrial devices which are expected to run 24/7 for the next 5
years at least. And they are updated from time to time.
I can agree with this statement.
quoted
Arnd has been nudging me to do DT conversion for EP93xx
so if there are many active industrial users of these
I should prioritize it, because these things have 20+ years
support cycles.
I'm not sure how important or necessary at all is to change anything
in these legacy platforms.
+1
quoted
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
But we should definitely preserve at least what we have.
I'm using OE to build toolchain (SDK). I can confirm that gcc 7.2 works
with it.
And yes, armv4 support shall be preserved in GCC ....
--
Alexander.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171213/d6dfd68c/attachment-0001.sig>
On Wed, Dec 13, 2017 at 9:26 AM, Alexander Sverdlin
[off-list ref] wrote:
On Wed Dec 13 08:34:22 2017 Linus Walleij [off-list ref] wrote:
quoted
Arnd has been nudging me to do DT conversion for EP93xx
so if there are many active industrial users of these
I should prioritize it, because these things have 20+ years
support cycles.
I'm not sure how important or necessary at all is to change anything in these legacy platforms.
I suspect that at several points in the next 5 to 10 years, we will remove
additional platforms or CPU types, as we tend to do when a platform
becomes a maintenance burden and is clearly not used by anyone.
It's hard to predict in advance what triggers the removal, but as the
number of platforms that are not using DT or ARCH_MULTIPLATFORM
goes down to a small number, there will be increased interested in either
removing or converting the remaining ones. This is not an immediate
danger at the moment, since we still have 14 platforms that are not
using ARCH_MULTIPLATFORM, and 23 that have remaining
board files, but you don't want to be the last user of the last platform
after the other ones are done ;-)
quoted
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
But we should definitely preserve at least what we have.
Plain ARMv4 (and earlier) support in gcc is already marked 'deprecated'
and will likely be gone in gcc-8 (it's still there as of last week). ARMv4T
is going to be around for a while, and you can even keep building for
ARMv4 using "-march=armv4t -marm" when linking with 'ld --fix-v4bx'.
Debian recently did a survey to find out whether there were still users
on ARMv4 or ARMv4T, and the result was that probably everyone is
on ARMv5E or ARMv6 for the ARM port (which is separate from the
ARMHF port that is ARMv7+). See also
https://lists.debian.org/debian-user/2017/11/msg00379.html
and let them know quickly if you use Debian stable releases and
plan to update to Debian 10 (Buster) in the future.
Arnd
On Wed, Dec 13, 2017 at 9:26 AM, Alexander Sverdlin
[off-list ref] wrote:
quoted
On Wed Dec 13 08:34:22 2017 Linus Walleij
[off-list ref] wrote:
quoted
Arnd has been nudging me to do DT conversion for EP93xx
so if there are many active industrial users of these
I should prioritize it, because these things have 20+ years
support cycles.
I'm not sure how important or necessary at all is to change
anything in these legacy platforms.
I suspect that at several points in the next 5 to 10 years, we will
remove additional platforms or CPU types, as we tend to do when a
platform becomes a maintenance burden and is clearly not used by
anyone.
I suppose that at least the last argument is not the case here :-).
It's hard to predict in advance what triggers the removal, but as the
number of platforms that are not using DT or ARCH_MULTIPLATFORM
goes down to a small number, there will be increased interested in
either removing or converting the remaining ones. This is not an
immediate danger at the moment, since we still have 14 platforms that
are not using ARCH_MULTIPLATFORM, and 23 that have remaining
board files, but you don't want to be the last user of the last
platform after the other ones are done ;-)
:-)
quoted
quoted
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
But we should definitely preserve at least what we have.
Plain ARMv4 (and earlier) support in gcc is already marked
'deprecated' and will likely be gone in gcc-8 (it's still there as of
last week). ARMv4T is going to be around for a while, and you can
even keep building for ARMv4 using "-march=armv4t -marm" when linking
with 'ld --fix-v4bx'.
I think that we shall start complaining on the gcc-devel mailing list
now.
I would be hard to wake up in 2 years time and realise that we don't
have a modern compiler.
Debian recently did a survey to find out whether there were still
users on ARMv4 or ARMv4T, and the result was that probably everyone is
on ARMv5E or ARMv6 for the ARM port (which is separate from the
ARMHF port that is ARMv7+). See also
https://lists.debian.org/debian-user/2017/11/msg00379.html
and let them know quickly if you use Debian stable releases and
plan to update to Debian 10 (Buster) in the future.
Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171217/56d4973a/attachment.sig>
On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski [off-list ref] wrote:
quoted
quoted
quoted
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
But we should definitely preserve at least what we have.
Plain ARMv4 (and earlier) support in gcc is already marked
'deprecated' and will likely be gone in gcc-8 (it's still there as of
last week). ARMv4T is going to be around for a while, and you can
even keep building for ARMv4 using "-march=armv4t -marm" when linking
with 'ld --fix-v4bx'.
I think that we shall start complaining on the gcc-devel mailing list
now.
I would be hard to wake up in 2 years time and realise that we don't
have a modern compiler.
What distro or build system are you using? It would also be helpful
to test whether the -march=armv4t/--fix-v4bx workaround produces
working binaries for you, in that case you could report to the gcc
developers that the removal of armv4 can continue but that
the --fix-v4bx option in ld needs to stay around.
Arnd
On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski [off-list ref]
wrote:
quoted
quoted
quoted
quoted
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
But we should definitely preserve at least what we have.
Plain ARMv4 (and earlier) support in gcc is already marked
'deprecated' and will likely be gone in gcc-8 (it's still there as
of last week). ARMv4T is going to be around for a while, and you
can even keep building for ARMv4 using "-march=armv4t -marm" when
linking with 'ld --fix-v4bx'.
I think that we shall start complaining on the gcc-devel mailing
list now.
I would be hard to wake up in 2 years time and realise that we don't
have a modern compiler.
What distro or build system are you using?
I'm using OE with the "include conf/machine/include/tune-arm920t.inc"
GCC 7.2 is working
It would also be helpful
to test whether the -march=armv4t/--fix-v4bx workaround produces
working binaries for you, in that case you could report to the gcc
developers that the removal of armv4 can continue but that
the --fix-v4bx option in ld needs to stay around.
I may ask this issue on OE/Yocto mailing list as well....
Thanks for hint.
Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171217/bec5a31a/attachment-0001.sig>
On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski [off-list ref] wrote:
Hi Arnd,
quoted
On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski [off-list ref]
wrote:
quoted
quoted
quoted
quoted
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
But we should definitely preserve at least what we have.
Plain ARMv4 (and earlier) support in gcc is already marked
'deprecated' and will likely be gone in gcc-8 (it's still there as
of last week). ARMv4T is going to be around for a while, and you
can even keep building for ARMv4 using "-march=armv4t -marm" when
linking with 'ld --fix-v4bx'.
I think that we shall start complaining on the gcc-devel mailing
list now.
I would be hard to wake up in 2 years time and realise that we don't
have a modern compiler.
What distro or build system are you using?
I'm using OE with the "include conf/machine/include/tune-arm920t.inc"
GCC 7.2 is working
Ah wait, this is still for ep93xx, which is always at least armv4t, right?
So it won't have a problem with the armv4 deprecation anyway, even
the older ep72xx/73xx were ARM720T based and don't have a problem.
I'm not entirely sure about their clps711x predecessors, which were some
earlier arm7 variant, but Linux doesn't support them any more anyway,
and the ARM710T would already be fine without --fix-v4bx.
quoted
It would also be helpful
to test whether the -march=armv4t/--fix-v4bx workaround produces
working binaries for you, in that case you could report to the gcc
developers that the removal of armv4 can continue but that
the --fix-v4bx option in ld needs to stay around.
I may ask this issue on OE/Yocto mailing list as well....
To clarify, the only affected platforms are those based on either
DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
FootBridge, RPC, SA1100, Moxart and Gemini.
Arnd
Hi!
On Mon Dec 18 12:55:40 2017 Arnd Bergmann [off-list ref] wrote:
quoted
quoted
GCC 7.2 is working
Ah wait, this is still for ep93xx, which is always at least armv4t,
right? So it won't have a problem with the armv4 deprecation
anyway, even
Correct.
Maybe a bit off topic :-)
Are there any more comments regarding this patch series? Are those
patches eligible for applying them to -next?
--
Alex.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171219/bc84a3eb/attachment.sig>
On Tue, Dec 19, 2017 at 10:36 PM, Lukasz Majewski [off-list ref] wrote:
Hi Arnd,
quoted
Hi!
On Mon Dec 18 12:55:40 2017 Arnd Bergmann [off-list ref] wrote:
quoted
quoted
GCC 7.2 is working
Ah wait, this is still for ep93xx, which is always at least armv4t,
right? So it won't have a problem with the armv4 deprecation
anyway, even
Correct.
Maybe a bit off topic :-)
Are there any more comments regarding this patch series? Are those
patches eligible for applying them to -next?
Alexander already sent a pull request, I just haven't pulled them. If there
are any other comments or additional patches, they should be done
on top of the first pull request, unless there is a major regression in
the original pull (which is unlikely).
Arnd
On Tue, Dec 19, 2017 at 10:36 PM, Lukasz Majewski [off-list ref]
wrote:
quoted
Hi Arnd,
quoted
Hi!
On Mon Dec 18 12:55:40 2017 Arnd Bergmann [off-list ref] wrote:
quoted
quoted
GCC 7.2 is working
Ah wait, this is still for ep93xx, which is always at least
armv4t, right? So it won't have a problem with the armv4
deprecation anyway, even
Correct.
Maybe a bit off topic :-)
Are there any more comments regarding this patch series? Are those
patches eligible for applying them to -next?
Alexander already sent a pull request, I just haven't pulled them. If
there are any other comments or additional patches, they should be
done on top of the first pull request, unless there is a major
regression in the original pull (which is unlikely).
Thanks for reply.
Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171220/391d72da/attachment-0001.sig>
On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski [off-list ref] wrote:
quoted
On Wed Dec 13 08:34:22 2017 Linus Walleij [off-list ref]
wrote:
quoted
On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski [off-list ref]
wrote: Out of curiosity: Liebherr is obviously doing heavy-duty
industrial control systems. Likewise Hartley is doing similar
business over at Vision Engravings.
Is the situation such that there is a whole bunch of industrial
systems out there, in active use and needing future upgrades,
that use the EP93xx?
That's definitely the case. I'm as well aware of several thousands of
industrial devices which are expected to run 24/7 for the next 5
years at least. And they are updated from time to time.
I can agree with this statement.
OK I'm coloring this platform with a highlight for ARM32 maintenance.
quoted
quoted
Arnd has been nudging me to do DT conversion for EP93xx
so if there are many active industrial users of these
I should prioritize it, because these things have 20+ years
support cycles.
I'm not sure how important or necessary at all is to change anything
in these legacy platforms.
+1
That is an understandable conservative stance.
There is a fine line between "it works, don't touch it" and
"modernize the ARM32 ecosystem".
There is a point where supporting old board files will stand in
the way and cost a lot in maintenance (like moving drivers our
of arch/arm, or modernizing misc subsystems). Then moving the
platform over to device tree should be preferred.
I'm using OE to build toolchain (SDK). I can confirm that gcc 7.2 works
with it.
And yes, armv4 support shall be preserved in GCC ....
Yes that is the same toochain I use.
Yours,
Linus Walleij
On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann [off-list ref] wrote:
On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski [off-list ref] wrote:
quoted
quoted
On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski [off-list ref]
wrote:
quoted
quoted
quoted
quoted
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
But we should definitely preserve at least what we have.
Plain ARMv4 (and earlier) support in gcc is already marked
'deprecated' and will likely be gone in gcc-8 (it's still there as
of last week). ARMv4T is going to be around for a while, and you
can even keep building for ARMv4 using "-march=armv4t -marm" when
linking with 'ld --fix-v4bx'.
I think that we shall start complaining on the gcc-devel mailing
list now.
I would be hard to wake up in 2 years time and realise that we don't
have a modern compiler.
(...)
quoted
quoted
It would also be helpful
to test whether the -march=armv4t/--fix-v4bx workaround produces
working binaries for you, in that case you could report to the gcc
developers that the removal of armv4 can continue but that
the --fix-v4bx option in ld needs to stay around.
I may ask this issue on OE/Yocto mailing list as well....
To clarify, the only affected platforms are those based on either
DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
FootBridge, RPC, SA1100, Moxart and Gemini.
It's a bit unfortunate since there are users and active contributors to
these architectures, I think the OE community is being missed out
just because they "are not Debian". :/
Even NetWinder.org is still up and kicking.
Some of it may be nostalgia and platform-hugging with regards to
SA110 and SA1100 systems, I am certainly aware of such tendencies
in myself. And I understand if GCC drops support for old systems
that only have a bunch of elderly gentlemen running it for the fun of it.
What really worries me is if there are widely deployed SA110,
SA1100, FA526 or similar embedded systems using plain ARMv4
and doing regular kernel builds and userspaces for them, in
items with 20+ years support cycles.
With reports in the media about things like nuclear powerplants running
unsupported versions of Windows NT or 95, I want to make sure
that we're not creating a similar situation somewhere for deeply
embedded Linux. Sadly these users mostly seem to come out
of the shadows after-the-fact.
My own experiments with an upgraded Gemini platform are mostly
related to the fact that home routers using this ARMv4 SoC are still
being sold and deployed, using a v2.6 kernel (contributing to the
world of botnets I suppose). The hardware-accelerated gigabit ethernet
on these routers for the home make them still fully usable despite the
ARMv4 core, but securitywise they are a nightmare.
Yours,
Linus Walleij
On Wed, Dec 20, 2017 at 1:33 PM, Linus Walleij [off-list ref] wrote:
On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski [off-list ref] wrote:
There is a point where supporting old board files will stand in
the way and cost a lot in maintenance (like moving drivers our
of arch/arm, or modernizing misc subsystems). Then moving the
platform over to device tree should be preferred.
I'm generally more interested in the multiplatform conversion than
the DT conversion, and I think converting this one to multiplatform
isn't actually that hard, and doesn't have a significant risk for
regressions, the main work is to convert the clock handling.
Arnd
On Wed, Dec 20, 2017 at 1:48 PM, Linus Walleij [off-list ref] wrote:
On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann [off-list ref] wrote:
quoted
On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski [off-list ref] wrote:
quoted
quoted
It would also be helpful
to test whether the -march=armv4t/--fix-v4bx workaround produces
working binaries for you, in that case you could report to the gcc
developers that the removal of armv4 can continue but that
the --fix-v4bx option in ld needs to stay around.
I may ask this issue on OE/Yocto mailing list as well....
To clarify, the only affected platforms are those based on either
DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
FootBridge, RPC, SA1100, Moxart and Gemini.
It's a bit unfortunate since there are users and active contributors to
these architectures, I think the OE community is being missed out
just because they "are not Debian". :/
IIRC, OE already uses the --fix-v4bx workaround. I had an older patch
to do the same in the kernel, let me resend it now, so you can try it
and see if that works for you.
Arnd