OMAP5: inconsistency between target-module and dsi_of_data_omap5

["H. Nikolaus Schaller" <hns@goldelico.com>]

Hi Tony,
since v5.7-rc1 our Pyra (OMAP5) dsi panel doesn't initialize and we do not
get a /dev/fb0.

There is a suspicious log message:

[   15.352314] DSI: omapdss DSI error: unsupported DSI module

I could trace it down to be likely a discrepancy between

target-module@58000000 { 

...

				target-module@5000 {
					compatible = "ti,sysc-omap2", "ti,sysc";
					reg = <0x5000 0x4>,
...
					ranges = <0 0x5000 0x1000>;

					dsi1: encoder@0 {
						compatible = "ti,omap5-dsi";

				target-module@9000 {
					compatible = "ti,sysc-omap2", "ti,sysc";
					reg = <0x9000 0x4>,
					      <0x9010 0x4>,
					      <0x9014 0x4>;

...

					ranges = <0 0x9000 0x1000>;

					dsi2: encoder@0 {
						compatible = "ti,omap5-dsi";
						reg = <0 0x200>,
						      <0x200 0x40>,
						      <0x300 0x40>;



and

static const struct dsi_of_data dsi_of_data_omap5 = {
	.model = DSI_MODEL_OMAP5,
	.pll_hw = &dss_omap5_dsi_pll_hw,
	.modules = (const struct dsi_module_id_data[]) {
		{ .address = 0x58004000, .id = 0, },
		{ .address = 0x58009000, .id = 1, },
		{ },
	},

Therefore the address match logic in dsi_probe() fails and ends in
the mentioned log message.

Looking at git blame, the DTS was recently changed by 5a507162f096b54.
Commit 98e1a6a86a22d62 did do a similar change for dsi2 but did not
modify the address.

So I wonder if the 0x5000 is just a typo or if there is something
where the dsi1: encoder@0 should have a negative offset to end
up at address 0x58004000?

BR and thanks,
Nikolaus