TS-9370 initial support by aaron-ets · Pull Request #326 · embeddedTS/linux-lts

aaron-ets · 2026-06-02T00:17:03Z

Initial support for TS-9370 i.MX93 board. Display, camera, sound not supported.

markfeathers

it looks like 6.18 added new checkpatch updates, or some of these may not have been met originally. For linux-lts though, we generally try to keep that passing with the exception:

DT compatible string "XX" appears un-documented

Those will be fixed when we prep for upstream.

Can you review / fixup the remaining checkpatch warnings? Eg:

scripts/checkpatch.pl --git 17cd437bfe05e601ba586d5e370eefa0ffb098aa

markfeathers · 2026-06-02T15:58:51Z

+	ret = regmap_read(data->regmap, SILO_RESERVED0, &version);
+	if (ret < 0)
+		return ret;
+	dev_info(dev, "TS-SILO version %d\n", version);
+	if (version < 2)
+		dev_warn(dev, "POWER_FAIL ignored without a Wizard interrupt controller.\n");


This should be removed, this version register wasn't being updated, and we shouldn't keep using it when its listed as a reserved register.

I'd suggest using ./scripts/checkpatch.pl --git fece377^..HEAD to run checkpatch against every commit here rather than just the HEAD 17cd437. There are a decent amount of warnings and errors that pop up overall. Many can be ignored though, probably.

The checkpatch warnings/errors I left in:

MAINTAINERS file needs to be updated

script wanted 4 lines of help text for Kconfig options

device tree missing docs

There were errors related to wanting () around the pinfunc.h macros, but those are used in the dts file which wouldn't like the (). I'm surprised checkpatch doesn't have a pincfunc override.

There were errors related to wanting () around the pinfunc.h macros, but those are used in the dts file which wouldn't like the (). I'm surprised checkpatch doesn't have a pincfunc override.

Yeah, it seems like just something they are dealing with. There may be a day when that comes, but today is not that day.

Everything else you mentioned makes sense and is something to pay closer attention to when upstreaming, case by case.

NXP FlexSPI(FSPI) BUS controller driver. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

Support for FPGA IRQ controller on TS-9370 board. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

aaron-ets · 2026-06-02T22:10:10Z

These were mostly just copied as-is from linux-tsimx. The only changes required were:

gpio get/set callbacks return int instead of void
structure of ti-adc128s052 driver changed, code to add adc121s021 support was adapted

ts-kris

A couple of small fixes, couple of comments that would be good to talk about.

ts-kris · 2026-06-02T22:05:21Z

I'm not sure about the organization of this, e.g. should it be in the freescale/ folder, or our own folder since its IOMUX for our FPGA? should it have imx93- as the prefix, since its a pinfunc for our 9370 FPGA that happens to have an i.MX93 CPU?

@markfeathers if you have any ideas of this, let me know. Otherwise I'll probably dig a little bit more just to find any other platforms that might be doing something like this and how they have their IOMUXes laid out.

ts-kris · 2026-06-02T22:11:12Z

+		assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_flexspi>;
+		//clock-frequency = <66666666>;


Remove this comment unless there is a specific reason to leave it as a reference, if so, please add a comment indicating under what circumstances it may be needed.

ts-kris · 2026-06-02T22:15:55Z

+			reg = <0x2000 0x200>;
+		};
+
+		fpga_gpio0: gpio@28000040 {


I'm only familiar with NXPs IOMUX setup, where they have the pinctrl node connected to each gpio instantiation in the devicetree with gpio-ranges, e.g.:

gpio1: gpio@209c000 { compatible = "fsl,imx6ul-gpio", "fsl,imx35-gpio"; ... gpio-ranges = <&iomuxc 0 23 10>, <&iomuxc 10 17 6>, <&iomuxc 16 33 16>; }; gpio2: gpio@20a0000 { compatible = "fsl,imx6ul-gpio", "fsl,imx35-gpio"; ... gpio-ranges = <&iomuxc 0 49 16>, <&iomuxc 16 111 6>; };

Does our driver not need anything like that? Mostly asking just to understand how our driver structure is set up since I otherwise see nothing linking the fpga_xbar and individual GPIO controllers. It would make sense if they don't need to be connected in most circumstances.

ts-kris · 2026-06-02T22:17:29Z

+		clock-frequency = <5000000>;
+
+		ethphy1: ethernet-phy@1 {
+			//compatible = "ethernet-phy-ieee802.3-c22";


Remove commented line unless it makes sense for some reason to leave it in, and if so, add a comment block explaining why it may be useful.

ts-kris · 2026-06-02T22:17:53Z

+		clock-frequency = <5000000>;
+
+		ethphy2: ethernet-phy@1 {
+			//compatible = "ethernet-phy-ieee802.3-c22";


Same as above

ts-kris · 2026-06-02T22:47:36Z

+obj-$(CONFIG_TS9370_IRQ)		+= irq-ts9370.o
+obj-$(CONFIG_WIZARD_IRQ)		+= irq-wizard.o
 obj-$(CONFIG_TSWEIM_FPGA_INTC)		+= irq-ts71xxweim.o


Suggested change

obj-$(CONFIG_TS9370_IRQ) += irq-ts9370.o

obj-$(CONFIG_WIZARD_IRQ) += irq-wizard.o

obj-$(CONFIG_TSWEIM_FPGA_INTC) += irq-ts71xxweim.o

obj-$(CONFIG_TS9370_IRQ) += irq-ts9370.o

obj-$(CONFIG_TSWEIM_FPGA_INTC) += irq-ts71xxweim.o

obj-$(CONFIG_WIZARD_IRQ) += irq-wizard.o

Reorder this to be in numeric/alphabetical order for consistency.

ts-kris · 2026-06-02T23:14:01Z

+#define MAX_IRQS	16
+
+#define IRQ_STATUS      0
+#define IRQ_ACK         1
+#define IRQ_MASK_SET    2
+#define IRQ_MASK_CLR    3
+#define IRQ_MASK_RW     4
+
+static const struct regmap_irq wizard_irqs[MAX_IRQS] = {
+	REGMAP_IRQ_REG(0, 0, BIT(0)),
+	REGMAP_IRQ_REG(1, 0, BIT(1)),
+	REGMAP_IRQ_REG(2, 0, BIT(2)),
+	REGMAP_IRQ_REG(3, 0, BIT(3)),
+	REGMAP_IRQ_REG(4, 0, BIT(4)),
+	REGMAP_IRQ_REG(5, 0, BIT(5)),
+	REGMAP_IRQ_REG(6, 0, BIT(6)),
+	REGMAP_IRQ_REG(7, 0, BIT(7)),
+	REGMAP_IRQ_REG(8, 0, BIT(8)),
+	REGMAP_IRQ_REG(9, 0, BIT(9)),
+	REGMAP_IRQ_REG(10, 0, BIT(10)),
+	REGMAP_IRQ_REG(11, 0, BIT(11)),
+	REGMAP_IRQ_REG(12, 0, BIT(12)),
+	REGMAP_IRQ_REG(13, 0, BIT(13)),
+	REGMAP_IRQ_REG(14, 0, BIT(14)),
+	REGMAP_IRQ_REG(15, 0, BIT(15)),
+};


From what I can tell, the preferred way of handling this, with the offset always being the same (0), is REGMAP_IRQ_REG_LINE() from 43fac32

#define REGMAP_IRQ_REG(_irq, _off, _mask) \ [_irq] = { .reg_offset = (_off), .mask = (_mask) } #define REGMAP_IRQ_REG_LINE(_id, _reg_bits) \ [_id] = { \ .mask = BIT((_id) % (_reg_bits)), \ .reg_offset = (_id) / (_reg_bits), \ }

Suggested change

#define MAX_IRQS 16

#define IRQ_STATUS 0

#define IRQ_ACK 1

#define IRQ_MASK_SET 2

#define IRQ_MASK_CLR 3

#define IRQ_MASK_RW 4

static const struct regmap_irq wizard_irqs[MAX_IRQS] = {

REGMAP_IRQ_REG(0, 0, BIT(0)),

REGMAP_IRQ_REG(1, 0, BIT(1)),

REGMAP_IRQ_REG(2, 0, BIT(2)),

REGMAP_IRQ_REG(3, 0, BIT(3)),

REGMAP_IRQ_REG(4, 0, BIT(4)),

REGMAP_IRQ_REG(5, 0, BIT(5)),

REGMAP_IRQ_REG(6, 0, BIT(6)),

REGMAP_IRQ_REG(7, 0, BIT(7)),

REGMAP_IRQ_REG(8, 0, BIT(8)),

REGMAP_IRQ_REG(9, 0, BIT(9)),

REGMAP_IRQ_REG(10, 0, BIT(10)),

REGMAP_IRQ_REG(11, 0, BIT(11)),

REGMAP_IRQ_REG(12, 0, BIT(12)),

REGMAP_IRQ_REG(13, 0, BIT(13)),

REGMAP_IRQ_REG(14, 0, BIT(14)),

REGMAP_IRQ_REG(15, 0, BIT(15)),

};

#define MAX_IRQS 16

#define IRQ_STATUS 0

#define IRQ_ACK 1

#define IRQ_MASK_SET 2

#define IRQ_MASK_CLR 3

#define IRQ_MASK_RW 4

static const struct regmap_irq wizard_irqs[] = {

REGMAP_IRQ_REG_LINE(0, MAX_IRQS),

REGMAP_IRQ_REG_LINE(1, MAX_IRQS),

REGMAP_IRQ_REG_LINE(2, MAX_IRQS),

REGMAP_IRQ_REG_LINE(3, MAX_IRQS),

REGMAP_IRQ_REG_LINE(4, MAX_IRQS),

REGMAP_IRQ_REG_LINE(5, MAX_IRQS),

REGMAP_IRQ_REG_LINE(6, MAX_IRQS),

REGMAP_IRQ_REG_LINE(7, MAX_IRQS),

REGMAP_IRQ_REG_LINE(8, MAX_IRQS),

REGMAP_IRQ_REG_LINE(9, MAX_IRQS),

REGMAP_IRQ_REG_LINE(10, MAX_IRQS),

REGMAP_IRQ_REG_LINE(11, MAX_IRQS),

REGMAP_IRQ_REG_LINE(12, MAX_IRQS),

REGMAP_IRQ_REG_LINE(13, MAX_IRQS),

REGMAP_IRQ_REG_LINE(14, MAX_IRQS),

REGMAP_IRQ_REG_LINE(15, MAX_IRQS),

}

The former in our case producing, e.g.

[0] = { .reg_offset = 0, .mask = (1 << 0) }, [1] = { .reg_offset = 0, .mask = (1 << 1) }, [2] = { .reg_offset = 0, .mask = (1 << 2) },

And the latter producing (reordered for consistency):

[0] = { .reg_offset = ((0/16) == 0), .mask = (((1 << 0) % 16) == 1) } [1] = { .reg_offset = ((1/16) == 0), .mask = (((1 << 1) % 16) == 2) } [2] = { .reg_offset = ((2/16) == 0), .mask = (((1 << 2) % 16) == 4) }

This may not be worth changing for this PR, but may need to be kept in mind when upstreaming later.

ts-kris · 2026-06-02T23:29:48Z

It looks like our defconfig defaults to having SOC_IMX8 as well as a handful of other default enabled i.MX8 drivers like clocks etc that I don't think we need? Unless the i.MX9 uses those under the hood. Would potentially benefit us to do a sweep and disable things like that which we don't need for sure to save some space.

SOC_IMX8M and SOC_IMX9 are both set by default ARCH_MXC && ARM64. We could roll this sweep into the defconfig cleanup task, does not seem like these defconfig files will be upstreamable anyway.

Correct, which is why for us, it would make sense to trim that out to save on unnecessary additional dead code. I'm find if you open an Issue and we kick it down the road a bit, if you prefer.

We were forced to enable them on the nxp kernel fork because many of the forked nxp drivers are not buildable if you disable some of those options. I'd expect we are able to trim this a bit more safely on the LTS kernels.

ts-kris · 2026-06-02T23:32:34Z

I don't have a better answer for this right now, but I'm not a fan of having separate selections for both platforms. It might be cleaner to have a single config option that is per CPU series, since in most cases they would both/all be enabled in our defconfigs, and it would require tuning for specific platforms if a customer wanted that.

It may also be a bright idea to completely hide these (or at least have some reverse dependency saying that if the ts9370 GPIO driver was selected, then select the pinmux driver too).

I could just remove 9390 for the moment and punt until we have one to test, I didn't copy over the 9390 device trees anyway.

I don't have a preference, nor an answer, but it should be something we look at closer before we upstream this.

ts-kris · 2026-06-02T23:41:16Z

+	int ret;
+	int irq;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);


Return of devm_kzalloc() is unchecked

Updated to return ENOMEM

Adding pinctrl drivers for ts9370 and tsxbar. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

TS-9370 expanded GPIO support. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

Interrupts from embeddedTS wizard microcontroller. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

Add single channel ADC121S021 ADC chip support to the TI ADC128S052 driver. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

Adding driver for TS-SILO supercap power supply. The TS-SILO provides power long enough for the system to be able to shut down gracefully if power is lost. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

Driver code comes from commit 1a07aaa2a9980ba2829d1a1733968c89f5a77ef3 of https://git.ti.com/git/lpaa-android-drivers/tac5x1x-linux-driver.git

Device tree and kernel defconfig for the embeddedTS TS-9370 i.MX93 Single Board Computer. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

calibration offset was using the wrong register.

aaron-ets requested review from luckshot, markfeathers and ts-kris June 2, 2026 00:17

markfeathers requested changes Jun 2, 2026

View reviewed changes

aaron-ets added 2 commits June 2, 2026 19:10

drivers: bus: Add nxp-fspi-bus

dc4bcc9

NXP FlexSPI(FSPI) BUS controller driver. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

drivers: irqchip: Add irq-ts9370

e1c8b56

Support for FPGA IRQ controller on TS-9370 board. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

aaron-ets force-pushed the tsimx9 branch from 17cd437 to 4e38057 Compare June 2, 2026 20:34

ts-kris requested changes Jun 2, 2026

View reviewed changes

aaron-ets added 6 commits June 4, 2026 23:14

drivers: pinctrl: Adding technologic pinctrl

1139199

Adding pinctrl drivers for ts9370 and tsxbar. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

drivers: gpio: Adding gpio-ts9370

204b650

TS-9370 expanded GPIO support. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

drivers: irqchip: Adding irq-wizard

e99c2f9

Interrupts from embeddedTS wizard microcontroller. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

iio: adc: ti-adc128s052: Adding adc121s021 support

bad546a

Add single channel ADC121S021 ADC chip support to the TI ADC128S052 driver. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

drivers: power: Adding tssilo driver

46ec3d9

Adding driver for TS-SILO supercap power supply. The TS-SILO provides power long enough for the system to be able to shut down gracefully if power is lost. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

sound: codecs: Adding tac5x1x-i2c driver

8e851d8

Driver code comes from commit 1a07aaa2a9980ba2829d1a1733968c89f5a77ef3 of https://git.ti.com/git/lpaa-android-drivers/tac5x1x-linux-driver.git

aaron-ets force-pushed the tsimx9 branch from 602a5bc to 300e91b Compare June 4, 2026 23:26

aaron-ets added 2 commits June 9, 2026 00:12

arm64: Adding TS-9370 device tree and config

7f095e7

Device tree and kernel defconfig for the embeddedTS TS-9370 i.MX93 Single Board Computer. Signed-off-by: Aaron Brice <aaron@embeddedts.com>

rtc: tswizard: Fix calibration offset

6168314

calibration offset was using the wrong register.

aaron-ets force-pushed the tsimx9 branch from 300e91b to 6168314 Compare June 9, 2026 00:12

Conversation

aaron-ets commented Jun 2, 2026

Uh oh!

markfeathers left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aaron-ets commented Jun 2, 2026

Uh oh!

ts-kris left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants