On Mon, 15 Jan 2024 19:07:30 +0000 "Srinivasan, Usha" <usha.srinivasan@xxxxxxxxxxxxxxxxxxxx> wrote: > Hi, Hugo. > We fixed our clock issue in the platform; and you were right, I need to bump the delay to 100 in addition. I pulled in the latest version of max310x.c from torvals linux and I still get the "nobody cared" stack traces & the interrupts get disabled. I'm hoping you can help me get beyond this. > > 57: 100001 0 1e780000.gpio 152 Level 11-006c > 58: 500001 0 1e780000.gpio 153 Level 11-0061 > 59: 100001 0 1e780000.gpio 154 Level 11-0062 > 60: 100001 0 1e780000.gpio 155 Level 11-0064 > [ 88.832861] [<da8c4f2b>] irq_default_primary_handler threaded [<ac7ce979>] max310x_ist > [ 88.841725] Disabling IRQ #57 > [ 175.370303] [<da8c4f2b>] irq_default_primary_handler threaded [<ac7ce979>] max310x_ist > [ 175.379166] Disabling IRQ #59 > [ 262.242889] [<da8c4f2b>] irq_default_primary_handler threaded [<ac7ce979>] max310x_ist > [ 262.251752] Disabling IRQ #60 > [ 369.903466] [<da8c4f2b>] irq_default_primary_handler threaded [<ac7ce979>] max310x_ist > [ 369.912332] Disabling IRQ #58 > > Thank you. > Usha > External recipient Hi Usha, please respond to the original email thread, so that people can see what has been done so far and better help you. With your crystal issues solved, do you see the exact same problem as before? Can you confirm with a voltmeter or an oscilloscope that your IRQ pin is behaving properly before and after you insert the max310x kernel module? Maybe it could help if you shared your DTS configuration. Also, just to be sure, you should not just pull the max310x source code itself, but use the whole tree to compile your kernel. Hugo Villeneuve
