14:41 <zmatt> tmlind: do you have any idea why linux (tested on 4.19-ti and 5.10-ti) on the dra7xx/am57xx leaves the requested power domain state for the cpu cores at ON (rather than INACTIVE or RETENTION), effectively rendering cpuidle ineffective?

14:42 <zmatt> I made a tiny util (https://github.com/mvduin/omap5-cpu-pm) that allows changing it to INACTIVE or RETENTION, and I get a 10 ͏°C cpu temperature reduction, from 61 to 51, with no _obvious_ ill effects

14:43 <zmatt> though I worry there might be some good reason cpu power management is disabled I'm unaware of

15:25 <zmatt> hmm, it seems to mess with system load measurement, at least on 4.19

22:59 <NishanthMenon> arnd: will be droppign in for elc, though lpc opened up earlier today, i would be missing the HIGH_MEM and the MC/arch discussions :(

23:11 <NishanthMenon> zmatt: 7abdb0e23e7bc8da685da5a54eb9f2f67f922ef2 (it ends up pointing at me)

23:22 <NishanthMenon> hmm.. https://lore.kernel.org/all/20140922131708.GA17009@kahuna/ i need to track down why since then i had suggested not to go into lower C states..

23:23 <NishanthMenon> https://lore.kernel.org/all/20161027161501.oehhwixykldta7hz@atomide.com/ but dont remember the context now.. :(

23:26 <NishanthMenon> aaah https://lore.kernel.org/all/c1b6bf69-ed11-3355-323f-9d6503180310@ti.com/ -> we ran into production issues and "descoped" it.

23:28 <NishanthMenon> zmatt: i think what you might be seeing is what we also saw when i did the original patches, it mostly works, but production testing uncovered issues around it - i dont think TI published the details in public, so might not be pertinent for me to share, the production tests however tend to be much rigorous than my usual desk based testing..

23:28 <NishanthMenon> rcn-ee: ^^ :(

23:40 <zmatt> NishanthMenon: sucks that it was dropped from investigation... I guess power management wasn't considered as important for the dra7, but on the other hand it does seem to have significant impact on temperature and the am5729-based BeagleBone-AI is known to suffer from overheating

23:44 <NishanthMenon> zmatt: yep. One of those '@#!' kind of deal. You could probably file an e2e.ti.com ticket, but I doubt it is going to get additional info. Rigor we had during old omap days dallied a bit back with lack of customer interest during dra7, though similar interest seems resurgent with am62 in k3 arch.. I guess tech fashion

23:45 <zmatt> maybe those customers tried to do pinmux on dra7 ;-)

23:46 <NishanthMenon> Uggh I was in front of VP with a presentation on why iodelay was a bad idea.. you are touching a very sore point for me

23:46 <zmatt> hehe, sorry

23:46 <NishanthMenon> No worries..

23:47 <zmatt> I mean, was it a bad idea or just badly implemented?

23:47 <NishanthMenon> Bad bugs

23:48 <NishanthMenon> Hence not worthy of production. Dynamic pinmux ... Let's just say, static config at boot people won't that round.

23:49 <zmatt> it certainly seemed a bit... heavyweight to use three programmable delay lines per I/O to line up your signal timing...

23:49 <NishanthMenon> Mmm... Tempting, but I will stay out of commenting ;)

23:51 <zmatt> but it sounds like dra7 is the first and last SoC with iodelay? ;)

23:52 <zmatt> just like dm816x was the first and last SoC with flying-adder PLLs

23:57 <NishanthMenon> zmatt: oh yes indeed, also the motivation why i took a few years sabbatical and joined forces with soc arch folks for k3 arch ;)