Hi Nikolaus,

Le lun., nov. 8 2021 at 19:33:48 +0100, H. Nikolaus Schaller 
[off-list ref] a écrit :

Hi Paul,

quoted

 Am 08.11.2021 um 18:49 schrieb Paul Cercueil [off-list ref]:

quoted

quoted

 Variant 4: the variant #2 without the changes to the DTSI files.

 Hm. If there is no cache and we can safely remove tight boundary 
checking (by JZ_REG_LCD_SIZE1) for jz4725/40/70 (by not fixing 
DTSI) why do we still need the max_register calculation from DTSI 
specifically for jz4780 and at all?

 It's better to have the .max_register actually set to the proper 
value. Then reading the registers from debugfs 
(/sys/kernel/debug/regmap/) will print the actual list of registers 
without bogus values. If .max_register is set too high, it will end 
up reading outside the registers area.

Ok, that is a good reason to convince me.

quoted

 On Ingenic SoCs such reads just return 0, but on some other SoCs it 
can lock up the system.

Yes, I know some of these...

quoted

 So the best way forward is to have .max_register computed from the 
register area's size, and fix the DTSI with the proper sizes. Since 
your JZ4780 code needs to update .max_register anyway it's a good 
moment to add this patch, and the DTSI files can be fixed later (by 
me or whoever is up to the task).

Well, it would already be part of my Variant #2 (untested). So I 
could simply split it up further and you can test the pure dtsi 
changes and apply them later or modify if that makes problems. Saves 
you a little work. BTW: the jz4740 seems to have even less registers 
(last register seems to be LCDCMD1 @ 0x1305005C).

Sure, if you want. Send the DTSI patch(es) separate from this patchset 
then.

quoted

 Fixing the DTS is not a problem in any way, btw. We just need to 
ensure that the drivers still work with old DTB files, which will be 
the case here.

Yes, that is right since the new values are smaller than the 
originals.

Ok, then let's do it that way.

Great. Waiting for your v6 then.

Cheers,
-Paul