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

[Ye Li]

Hi Michael, Emanuele,

On 11/12/2025 6:07 PM, Michael Nazzareno Trimarchi wrote:
> Hi all
> 
> On Wed, Nov 12, 2025 at 10:57 AM Emanuele Ghidoli
> <ghidoliemanuele at gmail.com> wrote:
>>
>>
>>
>> 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
>>
> 
> As is clear this problem was the same we had some months ago, so we
> are on the same page
> with Emanuele
> 
> Michael
> 


Can you help to measure the VDD_ARM_CAP and VDD_SOC_CAP on your devices 
with high temperature read issue, when REFTOP_VBGADJ is set to 3'b000 
and 3'b110 respectively. Provide the measured voltage and target voltage.
And please read the Unique ID fuse of this device by "fuse read 0 1 2".


Best regards,
Ye Li

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