[PATCH] imx: Revert "imx: mx6ull: fix REFTOP_VBGADJ setting" and fix comments

[Emanuele Ghidoli]

On 12/11/2025 09:16, Ye Li wrote:
> 
> 
> On 11/11/2025 9:47 PM, Fabio Estevam wrote:
>> Hi Emanuele,
>>
>> On Thu, Nov 6, 2025 at 7:22 AM Emanuele Ghidoli
>> <ghidoliemanuele at gmail.com> wrote:
>>
>>> Hi Fabio, Ye,
>>>
>>> At Toradex we have been struggling since quite some time (back to 2018) with
>>
>> Does this problem only affect early i.MX6ULL silicon samples?
> Hi Emanuele,
> 
>     I have same question as Fabio. Are these samples are early? Do you know
> the time of receiving these sample? And could you show the part number printed
> on the chip.
It could take a little to answer to the first two question. I can say that the
SoM I'm using to validate the patch was assembled in September 2021. Let me
know if this information are needed giving that I can report the marking on
the chip:
MCIMX6Y2CVM08AB CTDQ2107 1N70S CHINA QGDQCTA


> 
>>
>>> the temperature readings and the thermal shutdown behavior on i.MX6ULL. The
>>> issue we observed is that the thermal shutdown seems to trigger too early.
>>>
>>> I have investigated the history around this topic and verified some internal
>>> notes in our bug tracker. With this revert applied, and on the devices we have
>>> (all trimmed with value 0), the reported temperature increases by about 10 °C
>>> compared to before the revert. The absolute accuracy of the readout is
>>> questionable: for example, on a device kept at around 20 °C, the temperature
>>> readout was ~19 °C before the revert, and ~31 °C after the revert.
>>>
>>> Consider that for devices with fuse value of 6, there is a -10 degrees offset
>>> after this revert (so, the other way around).
>>>
>>> I understand that for Sven this revert improves stability during large XZ
>>> decompression in userspace for few devices, but for us it means that the
>>> thermal shutdown happens roughly 10 °C earlier, which is a serious issue in
>>> our case.
>>>
>>> I would kindly ask NXP to double-check how these devices were trimmed. My gut
>>> feeling is that there might be an inconsistency, either the trimming scheme is
>>> not backward-compatible (e.g. old and new devices behave differently, and the
>>> code should cope, I don't know how, with this), or this patch must be reverted
>>> (because introduces a regression).
>>
>> Peng/Ye Li,
>>
>> How does NXP suggest we handle this? Were the early i.MX6ULL parts
>> incorrectly fused?
> I need to discuss it internally, will feedback you later.
> 
>>
>> Can the fuse be read and dynamically adjusted?
>>
> The fuse is locked by MEM_TRIM_LOCK. Emanuele, can you help to read it by
> "fuse read 0 0 1".
Colibri iMX6ULL # fuse read 0 0 1
Reading bank 0:

Word 0x00000000: 00320003
Colibri iMX6ULL # fuse read 1 0 1
Reading bank 1:

Word 0x00000000: 00000080

Kind regards,
Emanuele

> 
> Best regards,
> Ye Li
>> Please advise, thanks.
>