<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 22.11.2023 10:29, Krzysztof
Kozlowski wrote:<br>
</div>
<blockquote type="cite"
cite="mid:39e9514b-087c-42eb-8d0e-f75dc620e954@linaro.org">
<pre class="moz-quote-pre" wrap="">On 22/11/2023 10:06, AngeloGioacchino Del Regno wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Hey Krzysztof,
This is interesting. It might be about the cores that are missing from the partial
core_mask raising interrupts, but an external abort on non-linefetch is strange to
see here.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I've seen such external aborts in the past, and the fault type has
often been misleading. It's unlikely to have anything to do with a
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yeah, often accessing device with power or clocks gated.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Except my commit does *not* gate SoC power, nor SoC clocks 🙂
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
It could be that something (like clocks or power supplies) was missing
on this board/SoC, which was not critical till your patch came.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
What the "Really power off ..." commit does is to ask the GPU to internally power
off the shaders, tilers and L2, that's why I say that it is strange to see that
kind of abort.
The GPU_INT_CLEAR GPU_INT_STAT, GPU_FAULT_STATUS and GPU_FAULT_ADDRESS_{HI/LO}
registers should still be accessible even with shaders, tilers and cache OFF.
Anyway, yes, synchronizing IRQs before calling the poweroff sequence would also
work, but that'd add up quite a bit of latency on the runtime_suspend() call, so
in this case I'd be more for avoiding to execute any register r/w in the handler
by either checking if the GPU is supposed to be OFF, or clearing interrupts, which
may not work if those are generated after the execution of the poweroff function.
Or we could simply disable the irq after power_off, but that'd be hacky (as well).
Let's see if asking to poweroff *everything* works:
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Worked.</pre>
</blockquote>
<p>Yes, I also got into this issue some time ago, but I didn't
report it because I also had some power supply related problems on
my test farm and everything was a bit unstable. I wasn't 100% sure
that the $subject patch is responsible for the observed issues.
Now, after fixing power supply, I confirm that the issue was
revealed by the $subject patch and above mentioned change fixes
the problem. Feel free to add:</p>
<p>Tested-by: Marek Szyprowski <a class="moz-txt-link-rfc2396E" href="mailto:m.szyprowski@samsung.com"><m.szyprowski@samsung.com></a><br>
</p>
<span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span>
<pre class="moz-signature" cols="72">Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland</pre>
<table id=bannersignimg data-cui-lock="true" namo_lock><tr><td><p> </p>
</td></tr></table><table id=confidentialsignimg data-cui-lock="true" namo_lock><tr><td><p><img unselectable="on" data-cui-image="true" style="display: inline-block; border: 0px solid; width: 520px; height: 144px;" src="cid:cafe_image_0@s-core.co.kr"><br></p>
</td></tr></table></body>
</html>
<table style='display: none;'><tbody><tr><td><img style='display: none;' border=0 src='http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=m.szyprowski&do=bWFpbElEPTIwMjMxMTI0MTI0MjM4ZXVjYXMxcDEyYmJkOTFkOTZjOWZjOWY3YzdhNzg0NDQ5ZTMyZTU0NyZyZWNpcGllbnRBZGRyZXNzPWRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmc_' width=0 height=0></td></tr></tbody></table>