@minlexx:
Unfortuntely among xiaomis tulip is device that was not tested dring the migration to mainline driver. It is possible that nvt-ts doesn't handle all variations of controllers that downstream driver does.

Downstream MiCode's tulip-perf_defconfig contains some config called CONFIG_TOUCHSCREEN_NVT_A, grepping it shows

./arch/arm64/configs/tulip-perf_defconfig:307:CONFIG_TOUCHSCREEN_NVT_A=y
./drivers/input/touchscreen/Makefile:75:obj-$(CONFIG_TOUCHSCREEN_NVT_A)         += nvt_touch_a/
./firmware/Makefile:144:fw-shipped-$(CONFIG_TOUCHSCREEN_NVT_A) += novatek/shenchao_nt36672a_miui_e7t.bin
./firmware/Makefile:145:fw-shipped-$(CONFIG_TOUCHSCREEN_NVT_A) += novatek/tianma_nt36672a_miui_e7t.bin

perhaps e7t is some kind of touchscreen variation? There are 3 subdirectories in https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/tulip-p-oss/drivers/input/touchscreen : nvt_touch_a, nvt_touch_d2s, nvt_touch_e7s, maybe if you diff those 3 dirs you'll know what are the differences.
Perhaps quicker simpler and more proper solution would be to add new compatible and new struct with matching fields. Similar to https://elixir.bootlin.com/linux/v6.18.2/source/drivers/input/touchscreen/novatek-nvt-ts.c#L321 but with values matching your tulip.

static const struct nvt_ts_i2c_chip_data nvt_nt36672_e7t_ts_data = {
	.wake_type = INSERT CORRECT VALUE HERE,
	.chip_id = INSERT PROPER VALUE HERE,
};

static const struct of_device_id nvt_ts_of_match[] = {
	{ .compatible = "novatek,nt11205-ts", .data = &nvt_nt11205_ts_data },
	{ .compatible = "novatek,nt36672a-ts", .data = &nvt_nt36672a_ts_data },
+	{ .compatible = "novatek,nt36672-e7t-ts", .data = &nvt_nt36672a_e7t_ts_data },
	{ }
};