On Tue, 9 Jan 2024 21:25:03 +0000
"Srinivasan, Usha" <usha.srinivasan@xxxxxxxxxxxxxxxxxxxx> wrote:
> Hi Hugo.
> Thanks so much for your response.
>
> I was building with 6.1 had one patch but not the other. I brought over the 2nd patch as well but made no difference.
>
> I switched from 6.1 to 6.6 which has both patches and still the same issue.
>
> What do you suggest next?
> Usha
Hi,
let's hope that someone with more experience with this IC can help you.
In the meantime, see my comments below...
> > -----Original Message-----
> > From: Hugo Villeneuve <hugo@xxxxxxxxxxx>
> > Sent: Monday, January 8, 2024 5:30 PM
> > To: Srinivasan, Usha <usha.srinivasan@xxxxxxxxxxxxxxxxxxxx>
> > Cc: linux-serial@xxxxxxxxxxxxxxx
> > Subject: Re: max14830 irq
> >
> > On Mon, 8 Jan 2024 19:08:08 +0000
> > "Srinivasan, Usha" <usha.srinivasan@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > > Hello,
> > > I am trying to get max14830 working on our platform and I'm seeing a stack
> > trace for each of the UARTs in my device tree. I'm not sure what the fix is. I'm
> > running 6.1.15-580639a (OpenBMC 2.14.0) on ASPEED ast2600. Any help
> > appreciated.
> > > [ 2.608620] max310x 11-006c: clock is not stable yet
I assume that your clock source is defined as a crystal (xtal) in your
device tree. Is it really the case (xtal vs oscillator)?
If yes, do you see this warning message every time? I noticed that
Boundary devices have a patch in their private repo where they
increased the delay to detect a stable crystal from 10ms to 100ms (but
they do not explain why).
Can you try that:
@@ -610,7 +610,7 @@ static u32 max310x_set_ref_clk(struct device *dev,
struct max310x_port *s, if (xtal) {
unsigned int val;
- msleep(10);
+ msleep(100);
regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val);
Hugo Villeneuve
> > > [ 2.614933] 11-006c: ttyMAX0 at I/O 0x0 (irq = 57, base_baud = 3750000) is a
> > MAX14830
> > > [ 2.625532] 11-006c: ttyMAX1 at I/O 0x1 (irq = 57, base_baud = 3750000) is a
> > MAX14830
> > > [ 2.636061] 11-006c: ttyMAX2 at I/O 0x2 (irq = 57, base_baud = 3750000) is a
> > MAX14830
> > > [ 2.646513] 11-006c: ttyMAX3 at I/O 0x3 (irq = 57, base_baud = 3750000) is a
> > MAX14830
> >
> > Hi,
> > it seems you have I2C communication with your device and the ID register was
> > read correctly in the probe() function. If it was not the case, you would have an
> > error message about that.
> >
> > > And,
> > > [ 88.430219] irq 57: nobody cared (try booting with the "irqpoll" option)
> >
> > This is probalbly happening because max310x_ist() was called, but when it
> > exited the interrupt line was still active, so that it was not handled properly.
> >
> > Can you make sure you have the following two patches in your kernel
> > version:
> >
> > 984a4afdc87a ("regmap: prevent noinc writes from clobbering cache")
> > c94e5baa989f ("serial: max310x: fix IO data corruption in batched
> > operations")
> >
> > I do not have hardware to test it, and this is a wild guess, but they may be
> > relevant to your problem because they enable the FIFOs to be read/written
> > properly. If Rx FIFO for example cannot be read, the source of the interrupt
> > cannot be cleared, and could potentially explain your problem.
> >
> > Hugo Villeneuve
> >
> >
> > > [ 88.437720] CPU: 0 PID: 65 Comm: irq/57-11-006c Not tainted 6.1.15-
> > 580639a #1
> > > [ 88.445687] Hardware name: Generic DT based system
> > > [ 88.451046] unwind_backtrace from show_stack+0x18/0x1c
> > > [ 88.456906] show_stack from dump_stack_lvl+0x40/0x4c
> > > [ 88.462556] dump_stack_lvl from __report_bad_irq+0x44/0xc8
> > > [ 88.468784] __report_bad_irq from note_interrupt+0x2c8/0x314
> > > [ 88.475208] note_interrupt from handle_irq_event+0x90/0x94
> > > [ 88.481436] handle_irq_event from handle_level_irq+0xbc/0x1b4
> > > [ 88.487952] handle_level_irq from generic_handle_domain_irq+0x30/0x40
> > > [ 88.495253] generic_handle_domain_irq from
> > aspeed_gpio_irq_handler+0xac/0x158
> > > [ 88.503326] aspeed_gpio_irq_handler from
> > generic_handle_domain_irq+0x30/0x40
> > > [ 88.511305] generic_handle_domain_irq from gic_handle_irq+0x6c/0x80
> > > [ 88.518411] gic_handle_irq from generic_handle_arch_irq+0x34/0x44
> > > [ 88.525316] generic_handle_arch_irq from call_with_stack+0x18/0x20
> > > [ 88.532328] call_with_stack from __irq_svc+0x98/0xb0
> > > [ 88.537973] Exception stack(0xbf925eb0 to 0xbf925ef8)
> > > [ 88.543614] 5ea0: 45854088 00000003 00000001
> > 00000000
> > > [ 88.552742] 5ec0: 00000000 4184ee80 45854088 00000000 45854000
> > 41a64140 00000000 00000000
> > > [ 88.561870] 5ee0: 00000000 bf925f00 4016bb7c 4016bac0 600f0013 ffffffff
> > > [ 88.569252] __irq_svc from __wake_up_common_lock+0x1c/0xb8
> > > [ 88.575483] __wake_up_common_lock from __wake_up+0x20/0x28
> > > [ 88.581714] __wake_up from irq_thread+0x118/0x1ec
> > > [ 88.587070] irq_thread from kthread+0xd8/0xf4
> > > [ 88.592040] kthread from ret_from_fork+0x14/0x2c
> > > [ 88.597288] Exception stack(0xbf925fb0 to 0xbf925ff8)
> > > [ 88.602923] 5fa0: 00000000 00000000 00000000
> > 00000000
> > > [ 88.612053] 5fc0: 00000000 00000000 00000000 00000000 00000000
> > 00000000 00000000 00000000
> > > [ 88.621179] 5fe0: 00000000 00000000 00000000 00000000 00000013
> > 00000000
> > > [ 88.628559] handlers:
> > > [ 88.631088] [<4f379e2c>] irq_default_primary_handler threaded
> > [<26199d83>] max310x_ist
> > > [ 88.639952] Disabling IRQ #57
> > >
> > > __________________________
> > > Usha Srinivasan
> External recipient
>
--
