Hi Daniel, Thanks again for the feedback. > -----Original Message----- > From: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> > Sent: Tuesday, August 5, 2025 12:06 PM > To: John Madieu <john.madieu.xa@xxxxxxxxxxxxxx> > Subject: Re: [PATCH v6 3/5] thermal: renesas: rzg3e: Add thermal driver for > the Renesas RZ/G3E SoC > > > Hi John, > > > On 05/08/2025 09:49, John Madieu wrote: > > [ ... ] > > >>> I might not get what you are asking, but since I compute the > >>> temperature in the hard IRQ handler, I just wait for it to complete > >>> and notify the completion so I can grab the processed value to > >>> notify the thermal core. > >>> > >>> Please let me know if this does not answer your question. > >> > >> Can you describe how the sensor works ? And perhaps if you have a > >> pointer to some documentation ? > > > > Here is the documentation [1]. The thermal device is referred to as TSU. > > > > [1] > > https://www.renesas.com/en/document/mah/rzg3e-group-users-manual-hardw > > are?r=25574493 > > > >> [ ... ] > > Thanks for the pointer. I got it now ;) > > I'm a bit worried about the latency introduced by this mechanism when the > system is entering in a thermal pressure episode. > > The get_temp function wait for a completion up to 100ms, it is a lot. > Especially if the userspace can be reading the temperature and blocking the > read. > > There is also the spin_lock taken introducing another lock while the > get_temp function is holding a mutex on the thermal zone. > > Did you it that under stress ? > After spending some time stressing the driver, I've noticed a couple of issues: * Spinlock/mutex mux caused some issues, and I had cases where it timed-out while not even under stress. * Mixing both compare (cmp) and conversion complete (conv) IRQs introduced some latencies and inconsistencies. After spending some time in the datasheet, I could notice that one conversion takes around 50µs. In average mode (8 samples per conversion), it would take 400µs, which I doubled (for margin) and used as timeout in v7 series that is already ready. Moreover, as per datasheet recommendations, I kept comparison IRQ (for trip point violation) only, while using polling for get_temp() (with the 800µs timeout), which gives better results. If you don't mind, I'll send a v7 which addresses all the requests from Geert as well as the above-mentioned changes. It includes: * 800µs timeout for get_temp() in polling read * No spinlock/mutex mix and no completion anymore * Comparison-only IRQ for trip point violations * + Geert's change requests What do you think ? Regards, John. > -- > <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | > <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro- > blog/> Blog
