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