Hi Nikolaus,
Le lun., nov. 8 2021 at 19:33:48 +0100, H. Nikolaus Schaller hns@goldelico.com a écrit :
Hi Paul,
Am 08.11.2021 um 18:49 schrieb Paul Cercueil paul@crapouillou.net:
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.
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...
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.
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