Re: [PATCH tty v11 1/2] serial: 8250: Switch to nbcon console, take 2

Jon Hunter <[email protected]>
Newsgroups gmane.linux.ports.tegra,gmane.linux.kernel,gmane.linux.serial
Message-ID <[email protected]>
On 27/08/2026 10:45, Thierry Reding wrote:
> On Thu, Aug 20, 2026 at 01:26:03PM +0206, John Ogness wrote:
>> On 2026-08-18, Petr Mladek <pmladek-IBi9RG/[email protected]> wrote:
>>>> [0] https://pastebin.com/FhQVSqfy
>>
>> ...
>>
>>> Almost everything works as expected except for:
>>>
>>>    1. I am not sure why "printk: console [ttyS0] disabled" is printed.
>>>       It does not make any sense to me.
>>
>> I have seen this in the past. It can happens unregister_console_locked()
>> has always printed the disabled message before actually checking if the
>> console is registered.
>>
>> IIRC it has something to do with serial8250_register_8250_port() calling
>> uart_remove_one_port(). I remember starting to look into how to fix it
>> but then was going down a rabbit hole that exceeded my scope at the
>> time.
>>
>>>    2. The WARNING would be handled with NBCON_PRIO_EMERGENCY.
>>>       I wonder if this warning happened also with "v5" of this
>>>       patchset.
>>
>> The tegra issue we had with v5 was related to irqwork being scheduled
>> when suspending. When keep_bootcon is specified, there will be no
>> irqwork scheduled during boot because legacy_direct=true.
>>
>>  From the backtrace in the posted boot log we see that the warning is
>> within tegra_pmc_enter_suspend_mode(). I am wondering if this is the
>> same issue we saw with v5... an irqwork getting scheduled when the tegra
>> is entering some suspend state.
> 
> You mentioning tegra_pmc_enter_suspend_mode() jogged a memory. We have
> to play some weird cpuidle tricks when PCI interrupts are anebled
> because of a hardware bug. That bug, as far as I know, is only Tegra20
> specific, so it doesn't explain this. In this particular case we're also
> not talking about PCI in this case, *but* I wonder if there's maybe
> other IRQ issues related to cpuidle.
> 
> It's a bit of a shot in the dark, but we could try disabling the various
> suspend modes via the PMC DT node. Notably LP2 seems to be the one
> that's causing issues on Tegra20 with PCI, so maybe changing
> nvidia,suspend-mode to something like 0 or 1 would help narrow things
> down?
By default 'nvidia,suspend-mode' is set to 1 for this board. In order,
to disable CPU idle CC6 state (CPU cluster off) I needed to remove this
property completely. Doing so does work around the problem and the
device boots.

Similarly, if I make the following change to ensure that CC6 is
disabled for Tegra20 and Tegra30 this also works for both Tegra20 and
Tegra30 ...

diff --git a/drivers/cpuidle/cpuidle-tegra.c b/drivers/cpuidle/cpuidle-tegra.c
index aca907a62bb5..d592e1f37f00 100644
--- a/drivers/cpuidle/cpuidle-tegra.c
+++ b/drivers/cpuidle/cpuidle-tegra.c
@@ -374,9 +374,11 @@ static int tegra_cpuidle_probe(struct platform_device *pdev)
         case TEGRA20:
                 /* Tegra20 isn't capable to power-off individual CPU cores */
                 tegra_cpuidle_disable_state(TEGRA_C7);
+               tegra_cpuidle_disable_state(TEGRA_CC6);
                 break;
  
         case TEGRA30:
+               tegra_cpuidle_disable_state(TEGRA_CC6);
                 break;
  
         case TEGRA114:

Jon

-- 
nvpublic
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.